¿Es esta área de administración lo suficientemente segura?

No implementes tu propio controlador de sesión. Use $ _SESSION , fue escrito y auditado por personas que comprenden muy bien la seguridad. Ni siquiera conozco las complejidades de cómo funciona el controlador de tu sesión, pero en función de la poca información que nos has proporcionado es inseguro .

La inyección SQL es útil para obtener datos de la base de datos. Nosotros HASH contraseñas porque en el caso de que un atacante obtenga esta información, se verán obligados a descifrar el hash antes de que sea útil. Sin embargo, en su caso, no importa que sea vulnerable a CWE-257 , el atacante simplemente puede sacar el ID de sesión de la base de datos y usarlo para autenticarse.

También podría obtener acceso de administrador porque no ha mencionado OWASP a9 - Insufficient Transport Layer Protection . También eres vulnerable a Clickjacking , cada aplicación web es predeterminada. CSRF o "sesión de montar" ya se mencionó.

Habilite los indicadores de seguridad "httponly", "secure". Puede hacer esto por $ _SESSION configurando PHP .

Una estrategia de defensa en profundidad es planificar el fracaso y limitar el acceso que tiene su administrador. No permitir la carga de archivos o la ejecución de código . Esta es la razón número 1 por la que las instancias de Wordpress se piratean, una vez que tiene administrador en un sitio de Wordpress, tiene ejecución remota de código en el servidor. Wordpress también implementó su propio controlador de sesión en un punto, y lo adivinaron, era muy inseguro.

1. Las contraseñas deben estar truncadas, no encriptadas. La rutina más preferible probablemente sería bcrypt. El parámetro de repetición debe ajustarse de modo que el hashing de las contraseñas tome ... digamos ... 200 milisegundos, para reducir la fuerza bruta sin conexión de la contraseña. (fuera de línea significa que su sistema se vio comprometido y se obtuvo el hash) (200 milisegundos significa que su hardware, nubes alquiladas o clusters podrían ejecutar los hashes mucho más rápido)

2. El diagrama me parece razonable.

Sugerencias adicionales

• Evita bruta en línea fuerza. (en línea significa que usar sus programas php, solo se usarían si no tuvieran una copia del hash (como si no pudieran usar la fuerza bruta fuera de línea))

• Evite los ataques CSRF : cualquier llamada a su programa que tenga efectos secundarios debe requerir una clave aleatoria especial que provenga de una solicitud anterior con la misma cookie, para evitar que visite una página web que tiene un formulario invisible con una acción que apunta al comando de eliminación de su sitio web, que se ejecuta inmediatamente con javascript. O en el caso de obtener solicitudes que causen efectos secundarios, es posible que solo necesite ver un correo electrónico que tenga una etiqueta de imagen para ser atacado de esta manera.

• Prevenga los ataques XSS : alguien podría inyectar JavaScript o HTML en algunas columnas que hacen que se ejecute JavaScript externo, posiblemente enviando cookies, contenido de la página actual o cualquier otro contenido en su sitio usando su sesión, y es posible que se puedan modificar / eliminar.

• El Administración de sesión descrito tiene deficiencias. Consulte Respuesta de Rook .

Esta no es una lista exhaustiva.

Recomiendo mirar en este sitio web de seguridad de TI. Realmente expande tu conocimiento de seguridad.

Descargo de responsabilidad: soy un programador en varios idiomas, pero no PHP. Soy un entusiasta de la seguridad, pero no necesariamente un experto.

No olvide incluir controles no técnicos también, como la separación de tareas (que requieren la aprobación de más de un administrador para realizar cambios críticos) y tener un registro de auditoría para la responsabilidad.