Problemas de seguridad en el ejemplo del código de función "Recordarme"

1

Soy un principiante, y esto puede ser muy obvio para ti, pero estoy tratando de entender si hay problemas de seguridad con este ejemplo.

Hoy en Stack Overflow, vi el siguiente post: PHP Sessions Iniciar sesión con Recordarme .

La pregunta es sobre la creación de una función "Recordarme" para extender la sesión autenticada para las personas que han iniciado sesión.

La respuesta aceptada fue:

function setSession($username,$password,$cookie=null){
    // Other code for login ($_POST[]....)
    // $row is result of your sql query
    $values = array($username,$this->obscure($password),$row['id']);         
    $session = implode(",",$values);

    // check if cookie is enable for login
    if($cookie=='on'){
        setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');
    } else {
        $_SESSION["your_session_name"] = $session;
    }
}

Por lo tanto, mi pregunta no es sobre cómo debería hacer esto, pero ¿estoy en lo cierto en los problemas de seguridad que describí a continuación para este ejemplo de código?

Usando el Top 10 de OWASP como referencia, estos son los problemas que veo:

Problema 1:

Primero, podemos suponer que $session tiene la contraseña y el nombre de usuario porque $value contiene el nombre de usuario y la contraseña del usuario. También con esta línea:

setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');

La cookie tiene ahora las credenciales del usuario. Un gran error para mí, consulte Número 3 para obtener más información.

Problema 2:

Leí este OWASP article donde dicen que para evitar el CSRF necesitamos generar un ID aleatorio asociado a la SESIÓN o Cookie.

Obviamente, en este código no hay un identificador único o token que sea sospechoso para mí.

Problema 3:

También podemos imaginar que el sitio podría ser vulnerable a 'Cross-Site Scripting (XSS)'

De hecho, si las credenciales del usuario se almacenan en una cookie, podemos ejecutar un script simple y mostrar la cookie.

alert(document.cookie);

Pregunta

Estoy seguro de que puede haber otro problema, pero he expuesto el más obvio para mí. ¿Tengo razón en los problemas que he identificado? ¿Perdí algún otro problema importante de seguridad con este código?

    
pregunta mpgn 09.08.2014 - 16:53
fuente

2 respuestas

2

El almacenamiento de datos confidenciales en una cookie no es necesariamente inseguro, depende de cómo configure la cookie. La cookie debe configurarse como una cookie segura (limitada solo a HTTPS), la bandera HttpOnly debe establecerse para evitar las secuencias de comandos de lado a lado (la cookie no estará disponible desde javascript) y el dominio debe configurarse en el valor correcto dependiendo de la alcance de la cookie. Con esta configuración, está bien colocar el nombre de usuario en la cookie.

Con respecto a los otros datos en la cookie, es posible crear un triplete de nombre de usuario, token de serie y token de una sola vez. Este triplete se almacena en la base de datos y en la cookie y puede compararse para autenticar al usuario. Hay un artículo excelente que explica esta técnica en el blog de Barry Jaspan

Si desea una medida de seguridad adicional, puede cifrar aún más el valor de la cookie con una clave que se encuentra en el servidor para que los detalles, como el nombre de usuario y los tokens, no puedan ser leídos en el navegador ni siquiera por el propio usuario. Pero si tiene un entorno de carga equilibrada, tendrá que asegurarse de que la clave de cifrado se comparte entre todas las instancias utilizando su DB, por ejemplo.

En cuanto a la implementación específica mencionada en su ejemplo de código, existen algunas inquietudes:

  1. ¿Qué hace la función oscura? incluso si es de una sola manera tiene una función, sería más seguro utilizar un número pseudoaleatorio criptográficamente seguro
  2. ¿cuál es la idea del parámetro ID de fila? no se entiende y no es aleatorio
  3. no está claro qué significa cuando $ cookie no está 'activada'. Los valores de autenticación se almacenan en la sesión en lugar de en una cookie. Si $ cookie! = 'On' significa que las cookies están deshabilitadas, esta es una mala práctica, ya que la ID de sesión se mantendrá en la url.
respondido por el aviv 10.08.2014 - 11:01
fuente
0

Tienes razón con todos esos problemas. Esa implementación no es segura y podría conducir al robo de identidad.

Es incluso menos seguro que usar la autenticación básica HTTP, ya que esas cookies son vulnerables a los ataques XSS.

No se me ocurrió ningún otro problema aparte de los que proporcionaste. (¿No son suficientes?). Bueno, existe la identificación de la entrada del usuario en la base de datos en la cookie, por lo que podría ayudar en otros ataques ... Ya que no hay información sobre esa consulta, la única razón para incluir la identificación de la fila es busque la base de datos con ella en el próximo inicio de sesión, por lo que podría ser vulnerable a una inyección de SQL (aunque no es probable)

Todavía quedan demasiados detalles fuera de ese código (como la función "oscura" (¿reversible o hash?) o la consulta SQL implícita) de que la respuesta parece un poco débil. Quiero decir, ese código establece la cookie pero, ¿cómo utiliza esa cookie?

¿Y por qué almacena la contraseña "oculta" en el caché de sesión del servidor si no hay "cookie habilitada"? Quiero decir, ya tiene las contraseñas almacenadas en algún lugar (base de datos, LDAP, archivos sin formato, ...) por lo que no es necesario almacenarlas nuevamente. Eso aumenta el riesgo de que esas contraseñas sean robadas, ya que esos datos no se cifrarán en un directorio temporal del servidor.

    
respondido por el NuTTyX 09.08.2014 - 23:47
fuente

Lea otras preguntas en las etiquetas