Creando sesiones seguras de PHP

18

Ya he creado y refinado los sistemas de registro e inicio de sesión. Sin embargo, estoy convencido de que la parte difícil se produce cuando se crea una sesión. Por lo que sé, esto se debe tanto al secuestro como a la fijación. Que con toda honestidad no entiendo completamente el concepto de.

He navegado por Internet todo el día y he realizado una gran cantidad de investigación. Los siguientes artículos me han sido útiles hasta ahora:

Cómo crear sesiones a prueba de balas

Guía de seguridad de PHP: Sesiones

Hasta ahora tengo muy poco, realmente podría necesitar ayuda y orientación. Esto es algo de lo que tengo hasta ahora:

Cuando una contraseña de usuario coincide y han confirmado su identidad mediante el script de inicio de sesión, se llama a la siguiente función. La sesión se inicia en la parte superior de la secuencia de comandos de inicio de sesión.

function begin_session()
{
session_regenerate_id();
$_SESSION['valid'] = 1;
$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']);
} 

Estoy usando la variable $ _SESSION ['valid'] como simple en la que el usuario ha iniciado sesión en la confirmación. Estoy asignando la sesión a un único agente de usuario y dirección IP. Veo que el agente de usuario es bastante inútil ya que se puede falsificar fácilmente, pero creo que es mejor tenerlo en lugar de no tenerlo.

Para mí, es evidente que los usuarios con cambio de ip dinámico / dinámico se desconectarán ... pero todos los que me han dicho esto no han podido presentarme una mejor opción o me la han explicado mejor.

Luego, estoy usando la siguiente función para hacer coincidir el agente del usuario actual con el agente del usuario original registrado en la creación de la sesión.

    function authenticate()
{
session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR'])) {       
    session_destroy();
echo 'die';
    header('Location: http://website login page/');
    exit();     
}
}

En este momento, debido a mi falta de comprensión, no sé de dónde soy vulnerable ni a dónde puedo ir y hacer mejoras. Todo esto es muy nuevo para mí y por el momento al menos estoy tratando de aprender esto en mi tiempo libre. Todo es nuevo para mí y quiero asegurar el mejor trabajo.

    
pregunta TuKritical 13.11.2012 - 02:10
fuente

3 respuestas

15

Lo primero y más importante, ¡DEJA DE USAR MD5! es una función hash rota y ha estado rota por muchos años. También tienes que usar un hmac, llamar directamente a md5 es vulnerable a un ataque de extensión de longitud.

Probar la dirección IP es problemático porque este valor puede cambiar si el usuario está detrás de un equilibrador de carga, que es comúnmente utilizado por universos y oficinas corporativas.

El atacante siempre tendrá el agente de usuario, y este valor es muy fácil de fuerza bruta. La prueba de este valor no es de ninguna forma ni forma una "medida de seguridad". Es muy parecido a tener una variable is_attacker=no y asegurarse de que este valor sea "no", que es ¡UNA ÚLTIMA! Cuando veo a un programador haciendo esto, huelo sangre, si realmente piensan que esto ayuda a mejorar seguridad entonces probablemente hayan cometido otros errores.

Configure sus configuraciones de sesión de php de la siguiente manera:

session.cookie_httponly = 1 (helps mitigate xss)
session.session.use_only_cookies = 1 (prevents session fixation)
session.entropy_file = "/dev/urandom" (better entropy source)
session.cookie_lifetime = 0  (smaller exploitation window for xss/csrf/clickjacking...)
session.cookie_secure = 1 (owasp a9 violations)
    
respondido por el rook 13.11.2012 - 16:53
fuente
2

Esto puede ser solo una opinión personal ...

Almacenaría la información de la sesión en una base de datos y la referenciaría mediante un token almacenado en una cookie. ya no necesita la var "válida" ya que la base de datos cruzará la referencia del token y se asegurará de que se encuentre dentro del tiempo de vida permitido.

Puede elegir trabajar directamente con la cookie o usar la cookie para configurar la información de la sesión si lo desea. La sesión no es realmente necesaria. Aunque más simple, mejor.

Su token se puede generar cuando el usuario inicia sesión y, si lo desea, se regenera con cualquier carga de página, si desea mantenerlo en ciclo.

El agente de usuario y el addr remoto no son una buena base para un token, ya que pueden ser muy comunes para muchas personas. Piensa como un proxy para una universidad o algo así. Todos tendrán la misma ip. puede crear cualquier cadena aleatoria y sería suficiente siempre que sea única.

Independientemente de lo que elija hacer, la idea básica es mantener la cantidad de información en su sesión o las cookies al mínimo y lo más oscura posible. Sería difícil adivinar un token válido si establece la caducidad en un tiempo normal. Además, puede realizar un seguimiento de los intentos fallidos y bloquear los intentos que se acumulan en un corto período de tiempo.

También puede iniciar personas si una cuenta intenta iniciar sesión desde varias ubicaciones. En ese caso, el agente de usuario y la IP pueden ayudar a identificar intentos de acceso simultáneos.

    
respondido por el Kai Qing 13.11.2012 - 02:30
fuente
0

Actualmente estoy en una posición similar, observando todas las diferentes opciones y repercusiones de la seguridad de la sesión y es un gran desafío equilibrar la usabilidad y la seguridad con la posible debilidad del servidor, el transporte y el cliente. SSL es la mejor manera de proteger la capa de transporte y una configuración segura de cookies ayuda a la protección del cliente.

En términos de usar la dirección remota de $ Server hay problemas. Para algunos usuarios, este valor cambia con bastante frecuencia y un usuario que tiene que volver a ingresar su contraseña cada vez que se pone molesto. Para otros usuarios que tienen una dirección IP fija o un rango de direcciones IP, esto puede ayudar a hacer que sea más difícil de descifrar, especialmente si también se usa SSL. La IP remota no es una solución mágica en términos de seguridad, pero no hay nada en el ciberespacio. Combinando múltiples métodos de seguridad todo ayuda. Tratar de crear un perfil de usuario con el que las variables del servidor $ permanezcan constantes y qué cambios pueden ayudar a saber cuándo cerrar la sesión del usuario y solicitar la contraseña de una manera más oportuna y fácil de usar. Si el usuario se desconecta, cualquier intento de fuerza bruta en las otras variables de $ server como el agente de usuario o la codificación de idioma solo tendrá que esperar hasta que el usuario real vuelva a iniciar sesión.

La forma en que maneja múltiples fuentes de inicio de sesión también tiene sus problemas, ¿qué sucede si el usuario desea registrarse desde el trabajo, en casa o mientras está fuera? Al tener alguna información sobre cómo el usuario usa su cuenta en los primeros días, puede ser útil saber cuándo cerrar la sesión y solicitar la contraseña nuevamente más adelante. Como administradores e incluso con una seguridad cibernética perfecta, la forma en que los usuarios administran sus contraseñas seguirá siendo un problema y requerirá algunas facilidades para limpiar el desorden cuando suceda.

    
respondido por el Kevin Martin 13.03.2013 - 05:27
fuente

Lea otras preguntas en las etiquetas