Duda session hijacking

Ronin46 · #1 (**permalink**) 17/03/2013, 11:14

Hola,

Veamos, hay algo que nunca he acabado de entender de todo lo que leo de session hijacking.

Si un atacante es capaz de obtener el identificador de sesión se dice que para evitar que se lleve a cabo tal robo es el de hacer una comprobación, como por ejemplo la de testear el user agent del usuario (entre otras, pero centremonos en esto).

Esto lo entiendo, ya que si un usuario estaba navegando con Firefox y de repente hace una petición con IE significa que algo sospechoso ha ocurrido.

Ahora bien, el obtener el user agent es algo trivial si has sido capaz de obtener el id de sesión, así que se propone el uso de un token, como por ejemplo:

Código PHP:

  <?php 
 $token = $_SERVER['HTTP_USER_AGENT']; 
$token .= 'PalabraSecreta'; 
 $token = md5($token); 
 if ($_SESSION['token'] === $token) ... 
?>

Y es aquí donde yo me pierdo. Desde el momento en el que ese token se genera a partir de un dato que es exactamente el mismo para la víctima y al atacante, ¿qué más da la complejidad del token? Al final validarás contra lo que está guardado en el Id de sesión que es el mismo para los dos, así que se saltará el token.

También se propone el generar un token único, como por ejemplo:

Código PHP:

  <?php 
$token = md5(uniqid(rand(),TRUE)); 
$_SESSION['token'] = $token; 
?>

y luego el token resultante transmitirlo por GET o COOKIE, lo cual lo veo mejor que lo anterior, pero igualmente se me plantea lo mismo de antes: si un atacante ha sido capaz de obtener el ID de sesión, el obtener el resto de las cosas (parámetros GET o COOKIES) es igual de trivial.

Por más que busco no encuentro alguien que se pregunte lo mismo que yo, así que debo ser yo quien no se está percatando de algo. ¿Alguien me ilumina?

P.D: pregunta extra aunque relacionada. ¿por qué siempre que se habla de capturar datos se habla en el momento de que un usuario hace una petición al servidor web? ¿no se pueden capturar esos datos en el momento en el que el servidor web responde al usuario?

Saludos.

Nemutagk · #2 (**permalink**) 17/03/2013, 12:15

Independientemente de que es completamente inútil usar el user agent como validación al ser una variable entregada por el mismo navegador y que es sumamente facil manipular la idea es que se genere el token con el user agent en el momento que este inicia sesión, si el user agent cambia, es cuando te puedes percatar si la sesión cambio de navegador/cliente...

Cita:

Al final validarás contra lo que está guardado en el Id de sesión que es el mismo para los dos, así que se saltará el token

No, en realidad validarás el hash generado por los user agent (el que se genero al iniciar sesión y que debe estar guardado como una variable de sesión contra el hash() generado con el user agent de cada petición), si en el user agent cambia 1 solo caracter el hash resultante con md5() será diferente, por lo tanto puedes estar seguro que algo cambio en el cliente...

Ronin46 · #3 (**permalink**) 17/03/2013, 12:44

Cita:

No, en realidad validarás el hash generado por los user agent (el que se genero al iniciar sesión y que debe estar guardado como una variable de sesión contra el hash() generado con el user agent de cada petición), si en el user agent cambia 1 solo caracter el hash resultante con md5() será diferente, por lo tanto puedes estar seguro que algo cambio en el cliente...

Esta es precisamente la parte que no entiendo.

Un usuario se loguea y en ese momento se genera un md5 que contiene su user agent. El usuario hace otra petición y justo en ese momento alguien obtiene su id de sesión y su user agent.

Ahora el atacante configura su entorno para simular que es el usuario legítimo y envía una petición.
Desde el momento en el que ha modificado la cabecera del user agent correctamente... ¿qué más da que esa variable contra la que compruebas esté con el user agent sin codificar o codificado?
Para un mismo dato de entrada la función de codificación generará exactamente el mismo dato de salida por lo que el atacante pasará la validación.

Nemutagk · #4 (**permalink**) 17/03/2013, 12:46

Creo que no leiste lo mas importante en mi respuesta....

Cita:

Independientemente de que es completamente inútil usar el user agent como validación al ser una variable entregada por el mismo navegador y que es sumamente facil manipular...

Ronin46 · #5 (**permalink**) 17/03/2013, 13:30

Vale, de acuerdo.

Entonces centremonos en:

Código PHP:

 
 <?php 
$token = md5(uniqid(rand(),TRUE)); 
?>

Se genera un token de esa forma, que se almacena en una variable de sesión en el momento en el que el usuario hace login.

Por cada petición que hace el usuario se lee una variable GET o COOKIE que éste envía y que contiene el token generado, el cual se compara con la variable de SESSION.

Alguien podrá decir, así es más seguro, ya que el atacante no sólo tiene que obtener el id de sesión, si no también el parámetro GET o la COOKIE. A esto yo digo, si el atacante ha sido capaz de obtener el id de sesión, que obtenga un parámetro GET o una COOKIE es igual de trivial, ¿no?

Saludos.

#6 (**permalink**) 17/03/2013, 15:09

al lio

1- en el momento del login logueamos al usuario creamos sus credenciales y guardamos en la bd algo como (es un ejemplo)

Código PHP:

Ver original$token = rand(1000, 9999999);
 
$cadena_identificacion = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$token);

2- ya tenemos guardado todo en la bd , ahora creamos una cookie con el token generado

Código PHP:

Ver originalsetcookie("name_cookie", base64_encode($token));

3 - ya con todo esto hecho , en cada peticion comprobamos la cadena

Código PHP:

Ver originalif(isset($_COOKIE['name_cookie']))
{
 // consulta de la cadena de identificacion segun el identificador de session 
 
$cadena_identificacion = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].base64_decode($_COOKIE['name_cookie']);
 
if($row['cadena'] != $cadena_identificacion)
{
exit('session hijacking');
}
 
}

espero que te sirva la idea , es tan solo un ejemplo para que veas un poco la luz

Nemutagk · #7 (**permalink**) 17/03/2013, 15:12

En realidad no hay forma (que yo conosca) 100% segura sobre sesiones y hijacking, ya que el que se ah robado el ID de sesión tiene al alcance muchas formas de saltarse cualquier tipo de validación, unas mas faciles que otras, pero de aquí se separan 2 cosas, si tu sistema usa datos sumamente privados o datos sensibles lo mejor que puedes hacer es usar una conexión segura (https) y enviar por esa via las cookies y te quitas de problemas, el punto es que tanto guarda tu sistema y que tanto piensas "gastar" en la seguridad de tu sitio, no es lo mismo un foro, que un sitio que maneja datos bancarios...

#8 (**permalink**) 17/03/2013, 15:20

a lo dicho anteriormente me faltaria añadir que tambien es necesario añadir el id de session y añadirlo a la cadena , una vez echo esto , despues de una peticion se comprueba la cadena con la de la bd si es correcta volmenos a generar un nuevo session_id y un nuevo token y la cookie volvemos a guardarlo y asi sucesivamente .

nemutagk tiene mucha razon de que es tu proyecto ?? que datos sensibles de los usuarios almacenas???

Ronin46 · #9 (**permalink**) 17/03/2013, 18:43

Debo de estar completamente ofuscado xD.

webankenovi, tu código precisamente muestra lo que no entiendo, así que me voy a centrar en él.

¿Me puedes explicar para qué haces un hash de los datos de la cadena de identificación? Si un atacante es capaz de falsificar exactamente los datos de las cabeceras HTTP, la IP de la víctima y la cookie que contiene el token, ¿qué más da el hash o cualquier otro sistema súper complejo de encriptación que montes? A igualdad de datos de entrada, igualdad de resultado generado, así que la obtención de tu cadena de identificación es igual de vulnerable esté o no "hasheada".

El único motivo que puedo ver para "hashear" la cadena de identificación es porque el hash resultante (128 caracteres en este caso debido a que usas whirlpool) es más corto que la simple concatenación de todos los datos de la cadena de identificación.

P.D: Mi pregunta no se debe a que lo necesite implantar en algún proyecto, simple curiosidad formativa.

Saludos.

#10 (**permalink**) 18/03/2013, 12:01

Bueno como te digo nemutagk no hay nada 100% seguro sobre sesiones y hijacking , ahora como yo lo veo si a un usuario le roban las cookies saben su ip la id de session el user-agent y tal cres que es por una mala seguridad de la web o por una mala seguridad por parte del usuario ? ahora bien la web intentara en todo lo posible que si eso sucede no puedan autentificarse como ese usuario cualquier persona no autorizada .

- ese hash claro que es vulnerable yo solo te lo expuse como ejemplo pero ademas te especifique en otro mensaje posterior " es necesario añadir el id de session y añadirlo a la cadena , una vez echo esto , despues de una peticion se comprueba la cadena con la de la bd si es correcta volmenos a generar un nuevo session_id y un nuevo token y la cookie volvemos a guardarlo y asi sucesivamente "

ahora bien vamos a plantearlo de nuevo pero mas seguro.

login

// realizamos las verificaciones y consultas pertinentes y declaramos las sessiones

Código PHP:

Ver original$rand         = rand();
$token        = hash('whirpool',session_id().$rand);
$credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$token);
 
// guardamos en la bd del usuario sus credenciales
// y guardamos en la cookie el rand
 
setcookie("dmz_", base64_encode($rand));

comprobacion en todas las peticiones (paginas)

Código PHP:

Ver originalif(isset($_COOKIE['dmz_']))
{
    $rand         = base64_decode($_COOKIE['dmz_']);
    $token        = hash('whirpool',session_id().$rand);
    $credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$token);
     
    // realizamos una consulta en la bd y extraemos los credenciales guardados en el login y comparamos
 
    if($row['cadena'] == $credenciales)
    {
        // si es correcto generamos un nuevo session id y un nuevo rand y volvemos a guardar los credenciales
 
        session_regenerate_id();
 
        $rand         = rand();
        $token        = hash('whirpool',session_id().$rand);
        $credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].$token);
 
        // guardamos en la bd del usuario sus credenciales
        // y guardamos en la cookie el rand
 
        setcookie("dmz_", base64_encode($rand));
    }
    else
    {
        exit('session hijacking');
    }
}

el hash es para comparar los hashes resultantes aqui lo importante es regenerar el id de session como medida de seguridad hijacking

aqui ademas te dejo un link de owasp de administracion de sessiones donde tambien se habla de hijacking

https://www.owasp.org/index.php/Sess...nt_Cheat_Sheet

alex1084 · #11 (**permalink**) 18/03/2013, 12:10

Cita:

Iniciado por Ronin46

Debo de estar completamente ofuscado xD.

webankenovi, tu código precisamente muestra lo que no entiendo, así que me voy a centrar en él.

¿Me puedes explicar para qué haces un hash de los datos de la cadena de identificación? Si un atacante es capaz de falsificar exactamente los datos de las cabeceras HTTP, la IP de la víctima y la cookie que contiene el token, ¿qué más da el hash o cualquier otro sistema súper complejo de encriptación que montes? A igualdad de datos de entrada, igualdad de resultado generado, así que la obtención de tu cadena de identificación es igual de vulnerable esté o no "hasheada".

El único motivo que puedo ver para "hashear" la cadena de identificación es porque el hash resultante (128 caracteres en este caso debido a que usas whirlpool) es más corto que la simple concatenación de todos los datos de la cadena de identificación.

P.D: Mi pregunta no se debe a que lo necesite implantar en algún proyecto, simple curiosidad formativa.

Saludos.

Humildemente hago un aporte a lo que comentas, si bien es cierto nada es 100% seguro el hash que te comentan tu ahora lo criticas porque sabes como se construyo, en cambio quien te pueda robar el id no sabe exactamente que información contiene dicho hash por lo tanto le tomará un buen tiempo construirlo para reemplazarlo, por lo tanto depende de la creatividad de cada quien como construye sus hash para hacerle la vida mas dificil a quien decida robar tu sesion ahi depende de quien se aburre primero jajajajaja

Saludos...

#12 (**permalink**) 18/03/2013, 12:19

tambien es muy importante adoptar otras medidas de seguridad extra para el usuario como no propagar el id de session por la url .

muy buena aclaracion no lo hubiera hecho mejor alex1084

Código PHP:

Ver originalini_set('session.hash_function','whirlpool'); // md5 es el algoritmo por defecto
 
// para no propagar el id por url
 
ini_set('session.use_trans_sid',0);
ini_set('session.use_cookies',1);
ini_set('session.use_only_cookies',1);
 
// solo sera accesible la cookie desde http y no sera accesible para lenguajes de script
 
ini_set('session.cookie_secure',0);
ini_set('session.cookie_httponly',1);

siempre pongo el algoritmo whirpool pero es solo un ejemplo .

Nemutagk · #13 (**permalink**) 18/03/2013, 12:47

Y mi pregunta es, al final han pensado en los usuarios que tienen IP dinamica? con si algoritmo les denegarán el acceso en algún momento, y lo peor que puedes hacer es complicarle la vida a tus usuarios legales para intentar mantener a raya a los ilegales, los cuales, siempre tendrán una u otra forma de saltar este tipo de validaciones...

Cita:

...en cambio quien te pueda robar el id no sabe exactamente que información contiene dicho hash por lo tanto le tomará un buen tiempo construirlo para reemplazarlo...

Te equivocas, una persona que quiere secuestrar una sesión no necesita pensar en hash, algoritmos o lo que se te ocurra, si un usuario puede navegar sin problemas lo unico que tiene que hacer es duplicar la información que su navegador envia al servidor Y YA ESTA, no tiene que hacer mas, siguiendo tu lógica, el usuario legal tendría que saber como se construye el hash para que tenga una navegación fluida...

#14 (**permalink**) 18/03/2013, 12:54

Ccierto nemutagk en algun momento podria pasar pero como resolverias eso .

Nemutagk · #15 (**permalink**) 18/03/2013, 13:00

No me complico la vida, como ya dije todo depende del proyecto en que este trabajando, si no manejo datos importantes no me preocupo, implemento una seguridad basica, si alguien secuestra alguna sesión no tienen acceso a información critica, en cambio, si la aplicación maneja información sensible, implemento una conexión segura HTTPS y ya esta....

#16 (**permalink**) 18/03/2013, 13:06

esta muy bien ese planteamiento , pero aun asi sabes como se podria resolver lo de la ip dinamica por casualidad?

alex1084 · #17 (**permalink**) 18/03/2013, 13:12

Cita:

Iniciado por Nemutagk

........ si un usuario puede navegar sin problemas lo unico que tiene que hacer es duplicar la información que su navegador envia al servidor Y YA ESTA, no tiene que hacer mas, siguiendo tu lógica, el usuario legal tendría que saber como se construye el hash para que tenga una navegación fluida...

Siempre y cuando sepa que información enviarle.... pero igual creo que esto seria un tema de nunca terminar, muchos podemos definir distintos algoritmos para construir el hash y aunque tenga acceso a nuestro id no necesariamente sabrá que información enviarle al servidor como decía ahí depende de la creatividad de cada quien en la forma que los construye, y tienes mucha razón las conexiones https son mejores cuando manejamos información mucho mas delicada, pero como tu pregunta era referente a las sesiones por eso nos hemos enfocado en eso...

Ronin46 · #18 (**permalink**) 18/03/2013, 13:30

webankenovi gracias por los códigos ya que son bastante útiles y por el enlace (aunque el enlace ya lo había leído ayer que lo pusiste en otro post ;)) pero te estoy haciendo un examen de matemáticas y me estás respondiendo la vida de Alejando Magno jejeje.

Así que para centrar el tema me haré la pregunta y me responderé a mi mismo, a ver si os parece bien el razonamiento.

¿Para qué se hace un hash de los datos de la cadena de identificación (me es indiferente qué datos componen esta cadena de identificación)?
- Porque así la cadena resultante ocupa menos, se ahorran bytes en la base de datos.
- Porque si alguien accede a la base de datos directamente no puede saber qué datos componen la cadena de identificación, estás manteniendo en secreto tu fórmula de generación de la cadena de identificación.

Y ahora pregunta extra, ¿aporta más seguridad el "hashear" la cadena de identificación?
En cuanto a esta pregunta creo que Nemutagk ha clavado la respuesta. La respuesta es: no.

Cita:

una persona que quiere secuestrar una sesión no necesita pensar en hash, algoritmos o lo que se te ocurra, si un usuario puede navegar sin problemas lo unico que tiene que hacer es duplicar la información que su navegador envia al servidor Y YA ESTA, no tiene que hacer mas

Discrepo contigo alex1084, si yo hackease a alguien no me preguntaría que información mandar al servidor, simplemente mandaría toda la información del usuario hackeado tal cual, sin quitar ni poner nada, ¿para qué andar a pensar si un dato sobra o no? A igualdad de entorno, igualdad de resultado obtenido. Así pues no acabo de ver a dónde quieres llegar con que para ti es importante hashear la cadena de identificación.

Saludos.

alex1084 · #19 (**permalink**) 18/03/2013, 13:45

Cita:

Iniciado por Ronin46

webankenovi ............
Discrepo contigo alex1084, si yo hackease a alguien no me preguntaría que información mandar al servidor, simplemente mandaría toda la información del usuario hackeado tal cual, sin quitar ni poner nada, ¿para qué andar a pensar si un dato sobra o no? A igualdad de entorno, igualdad de resultado obtenido. Así pues no acabo de ver a dónde quieres llegar con que para ti es importante hashear la cadena de identificación.

Saludos.

Ok entiendo tu planteamiento y si es muy válido, la idea del hash es "una media de suguridad extra" que si bien no garantiza que sea 100% segura ayuda a garantizar un poco mas la seguridad, por ejemplo se me ocurre alguien puede construir su hash con la siguiente información, IP que realiza la petición, user agent, la fecha, y adicionar un par de datos X que se envien por get o post intencionalmente, tu me diras que esta información se puede obtener para enviarsela al servidor y es valido, pero la "media de seguridad" podria darse si cada vez que haga peticiones al servidor este me genere un hash y lo compare con el hash de la sesion si coincide que me de paso de lo contrario no me permita continuar... me diras que si la ip del cliente cambia... mmmm no creo que la ip del cliente cambie cada minuto...

#20 (**permalink**) 18/03/2013, 13:49

ALEX1084 se refiria a si te han secuestrado la id de session , evidentemente deberas saber que datos compone la verificacion para modificarlos y penetrar , si no los sabes los intentas modificar pero logicamente el usuario no sabra que datos son comparados de ahy lo que dice alex de la creatividad .

ahora si has sido hackeado logicamente te da igual el hash y todo lo demas , entras y listo o mejor aun guardas la contraseña y entras cuando quieras .pero si esto pasase no seria responsabilidad de la web si no del usuario , esto no es controlable de ahy que no pueda haber nada 100%100 seguro sobre hijacking

#21 (**permalink**) 18/03/2013, 13:54

no es igual esto

Código PHP:

Ver original$credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].rand());

que esto

Código PHP:

Ver original$credenciales = hash('whirpool', $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_ACCEPT_LANGUAGE'].rand().date('dmy').$_GET['arro'].time());

es un ejemplo pero verdad que cambia la cosa?

A ESO SE REFIERE ALEX1084 que con solo el robo de la id es necesario saber muchas mas cosas para adivinar el hash

- ademas si usamos geolocalizacion podemos aumentar la seguridad

- tambien los navegadores podrian implementar un id de usuario y que nunca pudiesen haber 2 iguales con lo cual guardando el id del navegador del usuario en la bd y verificando dicho id aumentaria la seguridad

contra mas medidas mas seguro sera navegar

Ronin46 · #22 (**permalink**) 18/03/2013, 14:05

Claro, la 2ª opción es mejor.

Bueno, como veo que nadie responde exactamente a mi pregunta me daré por respondido y entenderé que no he dicho ninguna burrada de ahí que nadie me corrija, jejeje.

Por cierto webankenovi, en el código que pusiste anteriormente, ¿no tienes problemas con la regeneración del ID de sesión en todas las peticiones? Porque si se producen dos peticiones del mismo usuario casi simultáneas (doble click en un enlace, llamadas AJAX...) creo que ese código daría lugar a pérdida de sesión. Habría que implementar algo que almacene las últimas credenciales generadas con un par de segundos de margen para evitar el problema de las peticiones simultáneas.

Había leído algo de eso en algún lado... a ver si encuentro el enlace...

#23 (**permalink**) 18/03/2013, 14:08

haber es tan solo de guia ahora tu piensa como aumentar la seguridad, como ves ahy muchos metodos , usa una buena logica

no te conteste pero si no has dicho ninguna burrada .

alex1084 · #24 (**permalink**) 18/03/2013, 14:10

Ronin46, creo que esa será una respuesta que nunca nadie te respondera... seria como preguntar ¿Que fué primero, el huevo o la gallina?...

Ronin46 · #25 (**permalink**) 18/03/2013, 14:11

Este es el enlace que andaba buscando: http://shiflett.org/articles/session...ing#comment-21

Cita:

There may need to be some tweaking to allow for near-simultaneous requests both of which are legitimate. I addressed it by comparing the request token presented in the cookie with not just "last-issued" token but also "second-last issued token", and imposed a limitation that the time-difference between the two must be no more than 3 seconds â€“ otherwise the 2 requests are not deemed near-simultaneous and the server kills the session under the suspicion that legitimate requests are accompanied by malicious requests.

#26 (**permalink**) 18/03/2013, 14:13

se podria verificar la hora guardada en una cookie/session por ejemplo y al recargar verificamos que si es menor de x segundos no haga nada y si es mayor regenere .

Ronin46 · #27 (**permalink**) 18/03/2013, 14:26

Cita:

se podria verificar la hora guardada en una cookie por ejemplo y al recargar verificamos que si es menor de x segundos no haga nada y si es mayor regenere

Sí, parece una buena solución. Cuando toque revisar el sistema de manejo de sesiones le daré un par de vueltas porque recuerdo que tenía puesto lo de regenerar el ID constantemente pero al final lo tuve que quitar porque en las peticiones AJAX era un cachondeo xD.

Por cierto Nemutagk

Cita:

si no manejo datos importantes no me preocupo, implemento una seguridad basica, si alguien secuestra alguna sesión no tienen acceso a información critica, en cambio, si la aplicación maneja información sensible, implemento una conexión segura HTTPS y ya esta

¿Haces una programación personalizada para cada proyecto? Lo digo porque si tienes tu propio framework o usas uno ya hecho, la seguridad de un sitio sin información confidencial y otro con información confidencial es exactamente la misma, lo único que cambiaría es que uno va por http y el otro por https. Puedo ver que a nivel de BD hagas "cosas" que hagan que una sea más segura que otra, pero a nivel de código imagino que tendrás lo mismo, si no se perdería la gracia del framework.

Saludos

Nemutagk · #28 (**permalink**) 18/03/2013, 15:37

Cita:

Iniciado por webankenovi

- ademas si usamos geolocalizacion podemos aumentar la seguridad

- tambien los navegadores podrian implementar un id de usuario y que nunca pudiesen haber 2 iguales con lo cual guardando el id del navegador del usuario en la bd y verificando dicho id aumentaria la seguridad

Oh por (tu deidad favorita), que leo aquí, estas dispuesto a sacrificar tanto tuya como la de tus usuarios el anonimato que da internet!, te aseguro que muchisima gente no estará dispuesto a darte a conocer su posición solo para aumentar un poco la seguridad, y lo repito hasta el cansancio, no se porque se rompen la cabeza, si tanto les preocupa la seguridad en el sitio pierden su tiempo, para eso ya se usa conexiones seguras con cifrados desde los 128bits hasta los 2048 y mas, con eso toda la conexión cliente/servidor esta segura, y por ultimo, espero que jamas o al menos tome muchisimo antes de que "alguien" se le ocurra generar un ID por cliente/navegador/equipo en internet, si ahora hacen locuras con cookies de seguimiento y demás no quiero imaginar después....

Cita:

Iniciado por Ronin46

¿Haces una programación personalizada para cada proyecto? Lo digo porque si tienes tu propio framework o usas uno ya hecho, la seguridad de un sitio sin información confidencial y otro con información confidencial es exactamente la misma, lo único que cambiaría es que uno va por http y el otro por https. Puedo ver que a nivel de BD hagas "cosas" que hagan que una sea más segura que otra, pero a nivel de código imagino que tendrás lo mismo, si no se perdería la gracia del framework.

Yo trabajo con frameworks, desde symfony 2 hasta zend framework/zf2, todo depende del proyecto que este realizando, incluso también trabajo con python o .net, pero obvio, todo depende del proyecto a realizar, referencia a la seguridad es, de nuevo, como ya eh dicho, al menos en cuanto a lo que se centra esta conversación si, es la misma, porque al menos con los códigos planteados aquí todos son vulnerables, si eh interceptado el ID de la sesión es porque tengo acceso a todas las cabeceras que son enviadas entre el cliente y el servidor, por lo tanto, solo necesito clonar dichas cabeceras, ahora si implementa lo de IP, si, tendrán un sistemas un poco mas seguro, pero ahora, solo molestarían a usuarios legales con IP dinamica....

#29 (**permalink**) 18/03/2013, 16:25

discrepo contigo nemutagk , yo no estoy dispuesto a sacrificar mi anonimato ni la de los usuarios ya que para la geolocalizacion el usuario tiene que aceptarlo o no es su decision halla cada uno , pero aun asi para quien acepte la seguridad de su cuenta sera mas segura , para una web de subir imagenes na mas no lo implementaria pero para algo mas complejo si y luego el user decidira si activarlo o no. ademas la web no tiene por que conocer la geolocalizacion del usuario al igual que no se conocen (o por lo menos asi deberia de ser) las contraseñas

ahora no es que nos rompamos la cabeza , pero en mi caso me quiero dedicar a la seguridad.

respecto a las conexiones seguras no son 100%100 seguras .

Nemutagk · #30 (**permalink**) 18/03/2013, 16:40

Cita:

Iniciado por webankenovi

discrepo contigo nemutagk , yo no estoy dispuesto a sacrificar mi anonimato ni la de los usuarios ya que para la geolocalizacion el usuario tiene que aceptarlo o no es su decision halla cada uno , pero aun asi para quien acepte la seguridad de su cuenta sera mas segura , para una web de subir imagenes na mas no lo implementaria pero para algo mas complejo si y luego el user decidira si activarlo o no.

ahora no es que nos rompamos la cabeza , pero en mi caso me quiero dedicar a la seguridad.

respecto a las conexiones seguras no son 100%100 seguras .

Si sabes que una conexión https no es 100% entonces para que te rompes la cabeza "diseñando" algoritmos que son 1000 veces mas vulnerables, y por una simple razón, la base de todos esos scripts son una conexión insegura en la cual se puede sniffear, interceptar o leer toda la información sin problema alguno ya que esta viaja en texto plano (para el que lo sabe hacer claro esta), por lo tanto, con el simple hecho de clonar el cliente puedes hacerte pasar por el sin problemas, aun si implementas la geolocalización esta es simple información que entrega el cliente al servidor, por lo tanto se puede clonar igualmente, pero bueno, estoy ya es buscarle demasiado, es un topico muy abierto, hoy por hoy, lo mas seguro en cuanto a conexiones en servidores http son las conexiones seguras HTTPS, no hay nada mas seguro, por ultimo, te repito que depende de tu aplicación, si tienes un foro creeme, nadie va a perder su tiempo rompiendo el certificado https, para eso existen mil sitios mas "suculentos" donde invertir ese tiempo y conocimiento...