start - ¿Qué necesito almacenar en la sesión de php cuando el usuario ha iniciado sesión?
session_destroy (9)
Actualmente cuando el usuario inició sesión, creé 2 sesiones.
$_SESSION[''logged_in''] = 1;
$_SESSION[''username''] = $username; // user''s name
Así que, aquellas páginas que requieren iniciar sesión, solo hago esto:
if(isset($_SESSION[''logged_id''])){
// Do whatever I want
}
¿Hay algún vacío de seguridad? Quiero decir, ¿es fácil hackear mi sesión? ¿Cómo la gente hackea sesión? y como lo prevengo ??
EDITAR:
Acabo de encontrar esto:
http://www.xrvel.com/post/353/programming/make-a-secure-session-login-script
http://net.tutsplus.com/tutorials/php/secure-your-forms-with-form-keys/
Acabo de encontrar los enlaces, ¿son esos métodos lo suficientemente buenos? Por favor da tus opiniones. Todavía no tengo la mejor respuesta todavía.
Terminología
- Usuario: Un visitante.
- Cliente: un software particular habilitado para la web instalado en una máquina en particular.
Entendiendo las sesiones
Para comprender cómo hacer que su sesión sea segura, primero debe comprender cómo funcionan las sesiones.
Veamos este trozo de código:
session_start();
Tan pronto como lo llame, PHP buscará una cookie llamada PHPSESSID (por defecto). Si no se encuentra, creará una:
PHPSESSID=h8p6eoh3djplmnum2f696e4vq3
Si se encuentra, toma el valor de PHPSESSID y luego carga la sesión correspondiente. Ese valor se llama session_id .
Eso es lo único que el cliente sabrá. Lo que agregue en la variable de sesión permanece en el servidor y nunca se transfiere al cliente. Esa variable no cambia si cambia el contenido de $_SESSION . Siempre permanece igual hasta que lo destruyas o se agote. Por lo tanto, es inútil tratar de ofuscar los contenidos de $_SESSION por medio de hashing o por otros medios, ya que el cliente nunca recibe o envía esa información.
Luego, en el caso de una nueva sesión, establecerá las variables:
$_SESSION[''user''] = ''someuser'';
El cliente nunca verá esa información.
El problema
Puede surgir un problema de seguridad cuando un usuario malintencionado roba el session_id de otro usuario. Sin algún tipo de verificación, entonces será libre de hacerse pasar por ese usuario. Necesitamos encontrar una manera de identificar de manera única al cliente (no al usuario).
Una estrategia (la más efectiva) consiste en verificar si la IP del cliente que inició la sesión es la misma que la IP de la persona que usa la sesión.
if(logging_in()) {
$_SESSION[''user''] = ''someuser'';
$_SESSION[''ip''] = $_SERVER[''REMOTE_ADDR''];
}
// The Check on subsequent load
if($_SESSION[''ip''] != $_SERVER[''REMOTE_ADDR'']) {
die(''Session MAY have been hijacked'');
}
El problema con esa estrategia es que si un cliente usa un equilibrador de carga, o (en una sesión de larga duración) el usuario tiene una IP dinámica, activará una alerta falsa.
Otra estrategia consiste en verificar el agente de usuario del cliente:
if(logging_in()) {
$_SESSION[''user''] = ''someuser'';
$_SESSION[''agent''] = $_SERVER[''HTTP_USER_AGENT''];
}
// The Check on subsequent load
if($_SESSION[''agent''] != $_SERVER[''HTTP_USER_AGENT'']) {
die(''Session MAY have been hijacked'');
}
La desventaja de esa estrategia es que si el cliente actualiza su navegador o instala un complemento (algunos se agrega al agente de usuario), la cadena de agente de usuario cambiará y activará una alerta falsa.
Otra estrategia es rotar el session_id en cada 5 solicitudes. De esa manera, el session_id teóricamente no permanece el tiempo suficiente para ser secuestrado.
if(logging_in()) {
$_SESSION[''user''] = ''someuser'';
$_SESSION[''count''] = 5;
}
// The Check on subsequent load
if(($_SESSION[''count''] -= 1) == 0) {
session_regenerate_id();
$_SESSION[''count''] = 5;
}
Puede combinar cada una de estas estrategias como desee, pero también combinará las desventajas.
Desafortunadamente, ninguna solución es infalible. Si su session_id está comprometido, está bastante acabado. Las estrategias anteriores son solo medidas de interrupción.
Cuando tuve este problema mientras construía SugarCRM, rastreé y validé la dirección IP del usuario (además de algunas otras cosas). Solo comparé las tres primeras secciones de la dirección IP. Esto permitió la mayoría de las direcciones IP localmente variables. También hice posible desactivar la validación de la dirección IP para instalaciones donde era común una variación importante en la dirección IP. Creo que solo comparar el comienzo de la dirección IP le ayuda con la seguridad sin agregar una limitación tan severa a su aplicación.
Ejemplo: "###. ###. ### .---" Solo se verificará la parte de la dirección IP marcada con ''#''.
192.168.1.101
192.168.1.102
192.168.1.XXX
Todos son considerados iguales.
Jacob
Este es el código de inicio de sesión habitual, se pueden hacer algunas mejoras para que sea más difícil de romper. Primero, puede hacer una suma de comprobación con el nombre de usuario y la hora de inicio de sesión o, alternativamente, una cadena predefinida (o un salt), y almacenarla en la sesión y compararla.
Así que cuando el usuario inicia sesión:
// not the most secure hash!
$_SESSION[''checksum''] = md5($_SESSION[''username''].$salt);
Y antes de entrar en una zona sensible:
if (md5($_SESSION[''username''].$salt) != $_SESSION[''checksum''])
{
handleSessionError();
}
De forma predeterminada, las sesiones a menudo se almacenan como archivos en el lado del servidor, y se coloca una cookie en el navegador del usuario para recordar a qué archivo referirse. Cuando se trata de la piratería de sesión, de alguna manera el pirata informático recupera suficiente información para duplicar el inicio de sesión o logró cambiar los datos de la sesión, utilizando la información de la cookie.
Podría codificar su propio manejo de sesión utilizando bases de datos para mayor seguridad. Algunos CMS más estrictos, como Joomla, también registran la IP. Sin embargo, esto causa problemas para las personas que usan ciertos ISP.
Esto es ridículo.
El secuestro de la sesión se produce cuando (por lo general, a través de un ataque de secuencias de comandos entre sitios) alguien intercepta su ID de sesión (que es una cookie que el navegador envía automáticamente al servidor web).
Alguien ha publicado esto por ejemplo:
Así que cuando el usuario inicia sesión:
// ¡No es el hash más seguro! $ _SESSION [''checksum''] = md5 ($ _ SESSION [''username'']. $ Salt);
Y antes de entrar en una zona sensible:
if (md5 ($ _ SESSION [''username'']. $ salt)! = $ _SESSION [''checksum'']) {
handleSessionError (); }
Vamos a pasar por lo que está mal con esto
- Sales - No está mal, pero no tiene sentido. Nadie está rompiendo tu maldito md5, a quién le importa si está salado
- comparando el md5 de una variable SESSION con el md5 de la misma variable almacenada en la SESSION, está comparando sesión con sesión. Si la cosa es secuestrada esto no hará nada.
$_SESSION[''logged_in''] = 1; $_SESSION[''username''] = $username; // user''s name $_SESSION[''hash''] = md5($YOUR_SALT.$username.$_SERVER[''HTTP_USER_AGENT'']);// nombre de usuario hash para evitar manipulación
¿Evitar la manipulación por parte de quién? faeries sesión mágica? Sus variables de sesión no serán modificadas a menos que su servidor esté comprometido. El hash solo está realmente allí para condensar bien la cadena en una cadena de 48 caracteres (los agentes de usuario pueden alargarse un poco).
Al menos, sin embargo, ahora estamos revisando algunos datos del cliente en lugar de verificar los datos de SESSION a SESSION, ellos revisaron el HTTP_USER_AGENT (que es una cadena que identifica el navegador), esto probablemente será más que suficiente para protegerlo, pero debe darse cuenta Si la persona ya ha tomado su sessionId de alguna manera, es probable que también haya enviado una solicitud al servidor de los tipos malos y le haya dado al agente malo su agente de usuario, por lo que un pirata informático inteligente falsificaría su agente de usuario y anularía esta protección.
Que es donde llegas a la triste verdad.
Tan pronto como su ID de sesión se vea comprometida, se irá. Puede verificar la dirección remota de la solicitud y asegurarse de que se mantenga igual en todas las solicitudes (como lo hice yo) y que funcionará perfectamente para el 99% de su base de clientes. Entonces, un día recibirá una llamada de un usuario que utiliza una red con servidores proxy con carga equilibrada, las solicitudes saldrán de aquí a través de un grupo de IP diferentes (a veces incluso en la red equivocada) y él estará perdiendo su Sesión izquierda derecha y centro.
Para evitar la fijación de la sesión, que es básicamente adivinar el SID o robarlo utilizando varios métodos. NO importa cuan sofisticada sea la lógica de su sesión, definitivamente será vulnerable al robo de sessid hasta cierto punto. Es por eso que tienes que regenerar la identificación cada vez que haces algo importante. Por ejemplo, si va a realizar una publicación o cambiar una configuración en el administrador, primero ejecute session-regenerate-id. Entonces el hacker tiene que pasar por el proceso de hackearte de nuevo. Básicamente, esto le da al pirata informático un disparo de una sola vez con una identificación con todo el tiempo que perdió.
http://us.php.net/manual/en/function.session-regenerate-id.php
O puedes cambiar la identificación cada turno
if ($ _ SESSION [''counter''] == 3) {session_regenerate_id (); $ _ SESSION [''counter''] == 0}
Además, $ _SERVER [''HTTP_USER_AGENT''] no es muy confiable. Trate de evitarlo no solo por esa razón, sino porque es conveniente para los piratas informáticos porque saben que los agentes son ampliamente utilizados para esto. En su lugar, intente usar $ _SESSION [''id_token''] = sha1 (alguna información loca como la memoria de archivos, el nombre de archivo, el tiempo).
Puede almacenar la dirección IP, la firma del navegador, etc. para identificar al usuario. En cada solicitud, compárelo con los valores actuales para ver si sucedió algo sospechoso.
Tenga en cuenta que algunas personas están detrás de los proveedores que utilizan direcciones IP absolutamente dinámicas, por lo que a menudo se desconecta la sesión.
Puede encontrar una guía sobre seguridad de sesión en PHP here .
Puede robar sesiones a través de javascript (XSS-> ataque de secuencias de comandos en el lado de la cruz). Siempre debe usar un hash MD5 con sal para asegurar su sesión.
Para evitar el secuestro de sesiones, debe poner el agente de usuario
$ _SERVER [''HTTP_USER_AGENT'']
en el hash también.
En tu ejemplo:
$_SESSION[''logged_in''] = 1;
$_SESSION[''username''] = $username; // user''s name
$_SESSION[''hash''] = md5($YOUR_SALT.$username.$_SERVER[''HTTP_USER_AGENT'']); // user''s name hashed to avoid manipulation
Antes de usar la sesión, asegúrese de que utiliza el hash correcto:
if (!$_SESSION[''hash'']==md5($YOUR_SALT.$username.$_SERVER[''HTTP_USER_AGENT''])){
die (''session hash not corrected'')
}