2011-02-23 12 views
5

Quiero saber el proceso que suelen seguir las aplicaciones web para mantener el inicio de sesión entre varias solicitudes y también cómo gestionan las cosas usando COOKIES.¿Concepto y lógica del sistema de inicio de sesión?

En mi formulario de inicio de sesión, estoy proporcionando la función "Recordarme".

Cuando el usuario inicia sesión, compruebo el nombre de usuario y la validez de la contraseña de la base de datos. Si es válido, entonces verifico si está seleccionado "Recordarme", en caso afirmativo, entonces se almacena el nombre de usuario y la contraseña en la sesión, formato encriptado. Y finalmente, almacenar el nombre de usuario y la contraseña en SESSION.

Cuando el usuario navega de una página a otra, primero ejecuto el script de comprobación de inicio de sesión que comprueba si hay algún valor en las cookies, valida el nombre de usuario y la contraseña de la base de datos para verificar su validez. Si no hay ningún valor en la cookie y hay algún valor en la sesión, entonces estoy obteniendo el valor de la sesión y no comprobándolo desde db.

No estoy comprobando el valor de la sesión de forma db para no presionar db innecesariamente, acelerar las cosas. En el caso de las cookies, se pueden modificar, por lo que es necesario verificarlas.

Esto es lo que mi concepto, ¿verdad? ¿Es el camino a seguir y normalmente el sitio web slike SO, y otros trabajos en este tipo de método?

¿O los sitios web comprueban la autenticidad del inicio de sesión en cada página cargada, no importa su sesión o en las cookies?

Por favor revise y dé su opinión y conceptos para este escenario.

Gracias!

+0

Posiblemente útil: [Membresía del usuario con PHP] (http://net.tutsplus.com/tutorials/php/user-membership-with-php/) – drudge

+0

@Prashant: Envíenme un correo electrónico a [email protected], Necesito discutir en privado. También por favor borre esto después de leer. –

Respuesta

13

En primer lugar, solo haz un seguimiento si alguien ha iniciado sesión. Después de eso, nos ocuparemos de la función "recordarme".

Para saber si hay alguien conectado, simplemente mira la matriz $_SESSION. Todo lo que está allí es porque lo pones allí antes. Por lo tanto, al procesar un formulario de inicio de sesión, si el nombre de usuario & es correcto, guarde el nombre de usuario, el ID de usuario o lo que sea en la sesión ($_SESSION['username'] = $username;).

Cada vez que el usuario carga una página, que acaba de comprobar

if (isset($_SESSION['username'])) { 
    // $_SESSION['username'] is logged in 
} else { 
    // nobody is logged in 
} 

No hay necesidad de almacenar la contraseña en el $_SESSION (de hecho, por motivos de seguridad, es mejor que lo guarde en cualquier lugar excepto hash en el base de datos).

Ahora, el "recuérdame" característica ... En primer lugar, algunas consideraciones:

  • Cualquier usuario puede modificar las cookies de su navegador, por lo que necesita para asegurarse de que la cookie enviada a la aplicación no ha sido manipulado.
  • Los usuarios pueden verificarlo en las computadoras públicas (bibliotecas más o menos), por lo que necesita un sistema para invalidar eso.
  • Si un usuario cierra la sesión de su aplicación, la cookie que lo recuerda debe borrarse.

Para el primer punto, imagine que en la cookie almacena el nombre de usuario del usuario para ser "recordado" (¡¡¡MUY INSEGURO !!). Eso significa que si un usuario crea una cookie para su aplicación web con el contenido 'joe', su aplicación pensará que el usuario joe es recordado en esa computadora, así que otorgue acceso a este atacante como si fuera joe.Por lo tanto, tenemos que cripta/hash la cookie de alguna manera.

Para el segundo punto, invalidar "recordarme" en algunas computadoras, usaremos la contraseña de alguna manera. Si algún usuario desea invalidar todas las computadoras en las que podría haber marcado la casilla "recordarme", todo lo que tiene que hacer es cambiar su contraseña. Eso también significa que si él/ella cambia su contraseña, todos los inicios de sesión guardados para su cuenta serán invalidados, por la misma razón exacta. Pero es mejor prevenir que lamentar ...

Entonces, cuando procesa un inicio de sesión y el nombre de usuario y la contraseña son correctos, y la opción "recordarme" está marcada, además de guardar el nombre de usuario en la sesión, almacena una hash del nombre de usuario & contraseña (y un poco de sal, si lo prefiere) en una cookie que envíe al usuario. También necesita almacenar en la cookie el nombre de usuario en texto sin formato (o encriptado de manera reversible) para saber qué usuario está intentando "iniciar sesión" a través de una cookie, y verificar el hash del nombre de usuario & contraseña en la cookie con el hash de nombre de usuario & contraseña en la base de datos. Si esa verificación es correcta, entonces almacena el nombre de usuario en la sesión y ya no verifica la cookie de este usuario (al menos para esta sesión).

tanto, en general el código podría tener este aspecto:

login.php

if (check_login($_POST['username'], $_POST['password'])) { 
    // login correct 
    $_SESSION['username'] = $_POST['username']; 
    if (isset($_POST['remember_me'])) { 
     // we hash the password because we **NEVER** store it in plain text anywhere 
     // so when we would like to check if the cookie value is correct, we will not 
     // be able to do so if the hash in the cookie was done from the plaintext 
     // password. 
     $value = sprintf('%s:%s', $_POST['username'], md5($_POST['username'].hash_password($_POST['password']))); 
     setcookie('rememberme', $value); 
    } 
    redirect('/your/home/page.php'); // view Post/Redirect/Get design pattern 
} else { 
    // login incorrect, show error message and whatever... 
} 

al principio de cada archivo PHP (o mejor, en un archivo incluido para arrancar su aplicación)

if (isset($_SESSION['username'])) { 
    // $_SESSION['username'] is logged in, proceed as you wish 
} else if (isset($_COOKIE['rememberme'])) { 
    // this user has checked the remember me feature some time ago in a previous login. 
    // let's check if it is valid. 
    list($username, $hash) = explode(':', $_COOKIE['rememberme']); 

    // we need to get the password hash stored for this user (remember you **NEVER** store passwords in plain text 
    $pwd_hash = obtain_password_hash_from_username($username); 
    if ($hash == sprintf('%s:%s', $username, md5($username.$pwd_hash))) { 
     // yeah, the user remembered is correct. We'll save it to the session to not do this shit again 
     $_SESSION['username'] = $username; 
    } else { 
     // the cookie value is not correct so maybe an attacker is trying to fool us, 
     // or the user changed his password. Whatever it is, we remove the cookie 
     // because it's no longer valid 
     setcookie('rememberme', '', time() - 3600); 
    } 

} else { 
    // this user is neither logged in nor "remembered" 
} 

el método de hash de la contraseña de usuario depende de usted. Es posible que desee un md5 o sha simple, un md5 o sha salado (mejor) o algún método que consuma tiempo, como blowfish (recomendado). Para hash la cookie he usado plain md5, pero puede elegir cualquiera de los métodos descritos anteriormente.

Creo que eso es todo.

+0

Esto es perfectamente correcto. ¿Pero qué pasa con el secuestro de sesión o algo similar que puede comprometer la sesión? ¿y es realmente que las sesiones pueden verse comprometidas tan fácilmente? – Prashant

+0

Para un secuestro de sesión, un atacante necesita acceso a la cookie de sesión. Esto es posible si el atacante se encuentra en algún lugar de la ruta de red entre el cliente y el servidor (Man-in-the-middle) o en la misma red no conmutada que el cliente o en la misma red wifi abierta. En estos casos, el atacante puede oler el tráfico, leer la cookie de sesión del usuario legítimo y secuestrar su sesión. La única defensa contra esto es la encriptación de extremo a extremo (SSL). –

+1

Otras formas en que un atacante puede obtener la cookie de sesión de un usuario legítimo es a través de un ataque XSS. Para escapar de este tipo de ataque, debe escapar de su salida a la página html (el mismo concepto que escaparse de los valores antes de consultar la base de datos para evitar inyecciones sql). A través de un XSS un atacante podría inyectar algunos javascript a su aplicación, y este javascript podría tratar de acceder a la cookie de sesión de un usuario legítimo. Para evitar cualquier javascript que acceda a sus cookies, utilice el indicador 'http_only' en' setcookie (...) 'y' session_set_cookie_params (...) ' –

Cuestiones relacionadas