php - sesion - probar lector de huellas online

Hashing una huella digital de sesión realmente necesaria? (8)

Por favor, lea esto CON MUCHO ANTES de votar ...

Así que he visto muchas clases de gestión de sesión que crean una huella dactilar mediante la concatenación del agente de usuario y un par de bloques de IP o lo que sea. Parece que también agregan una sal y luego comprimen esta huella digital antes de almacenarla en una variable de sesión.

Esta generación de huellas dactilares generalmente sucede a cada solicitud para verificar que el usuario actual de la sesión es, de hecho, el usuario de la sesión original. Esta es la razón por la que me pregunto: ¿es la sal y el hash realmente necesarios en algo como esto?

Si un pirata informático puede acceder a su sistema de archivos para ver el contenido de su archivo de sesión, ¿no está ya manguerado en ese punto?

Cualquier información muy apreciada.

Si un pirata informático puede acceder a su sistema de archivos para ver el contenido de su archivo de sesión, ¿no está ya manguito en ese punto?

Si está utilizando PHP como CGI (como en el caso de nginx), entonces creo que no. Si establece los permisos correctos, sus archivos de sesión deben tener permiso de lectura / escritura para el usuario de PHP, mientras que los archivos PHP deben tener solo permisos de lectura. Por lo tanto, si pasa la sal del servidor web a PHP, el usuario de PHP no puede tener acceso a él (no puede crear ningún archivo PHP nuevo / cambiarlo existente que pueda ejecutar su servidor web y no puede acceder al servidor web, ya que se ejecuta en otro usuario), por lo que realmente no puede piratear (cambiar) las cookies (solo eliminarlas) porque no puede obtener sal. Por supuesto, también tendrá que pasar la configuración de la base de datos del servidor web.

Nunca lo intenté realmente, así que por favor corrígeme si estoy equivocado.

es la sal y el hash realmente necesarios en algo como esto [huella digital del cliente http]?

El hash podría ser útil para reducir el número de bytes consumidos por la huella digital dentro de los datos de la sesión. Por lo tanto, siempre que la huella dactilar de hash sea de un tamaño más pequeño que la huella dactilar, esto puede tener sentido en términos de reducción de espacio. El precio es el consumo de recursos del sistema para generar el hash.

¿Realmente tiene sentido? Necesitaría comparar esto para decirlo.

¿Cómo puede ser útil una sal? Debo admitir que no veo ninguna razón para una sal. Tendría sentido hacer más difícil adivinar la huella dactilar de un hash. Pero como no veo ningún beneficio de seguridad en la manipulación de la huella dactilar (se mantiene solo en el lado del servidor y ya es considerablemente segura), la salazón no agrega nada.

En caso de que el almacén de sesiones en sí mismo no se considere seguro (si eso es para el argumento), toda la sesión debe ser encriptada , no solo la huella digital.

Así que particularmente para la huella dactilar, no veo mucho uso en el hashing y la salazón.

Como complemento a la respuesta de @Kai Sellgren (+1) que contiene algunas buenas pistas sobre cómo asegurar el almacenamiento de su sesión, agregaría algunas ideas que pueden explicar el hash y la sal en algunas aplicaciones específicas.

No estoy hablando de aplicaciones que están usando la cookie como almacenamiento de sesión, todavía vemos esto, por ejemplo, en la solución de comercio electrónico de Prestashop, con el cifrado del contenido de la cookie (¿por qué diablos decidieron almacenar la sesión en la cookie?) . Entiendo que hablamos sobre el almacenamiento de la sesión del lado del servidor.

El punto clave es la seguridad en capas y la defensa en profundidad :

Las conciliaciones nunca son cosas booleanas, no estás ''completamente comprometido'' o ''completamente seguro''. Una de las historias reales que me gusta es la explicación del gusano mySpace , muestra un ataque real y cómo deben romperse los pasos defensivos. Siempre hay una nueva pared. Solo un ejemplo, comparto la misma IP que mi jefe cuando estoy en la oficina, y tal vez el mismo navegador, esto podría romper una seguridad basada únicamente en IP + user-agent.

Así que en el hash & salt del sellado de sesión estamos actuando claramente después de que algunas paredes han caído. Y kai nos muestra algunas de estas paredes. Cuando habla de asegurar el almacenamiento de la sesión, agregaría 2 cosas:

es una muy buena idea alterar open_basedir y open_basedir de cada aplicación PHP (y obtener un Virtualhost separado para cada una). Raramente hecho.
si su aplicación está instalada en una ruta (como / myapp), agregue un prefix_path en la cookie de sesión (y corríjalo para cualquier otra aplicación en el mismo servidor)

Ahora imaginemos un compromiso realista. Hay varias formas de comprometer la sesión en el lado del servidor:

La aplicación se ejecuta en un sitio web con algunas otras aplicaciones que se ejecutan en otras rutas (o en otros dominios en el mismo servidor). Y al menos una de estas aplicaciones es bastante insegura. En el peor de los casos, el código del servidor podría ser inyectado en esta aplicación, pero algunos de los muros de seguridad (como open_basedir u otras técnicas de enganche) pueden evitar que este código inyectado afecte a su aplicación (o datos) por separado.
Algunas de las bibliotecas javascript vienen con algunos subdirectorios de prueba que contienen scripts altamente inseguros, con no solo buena divulgación de sesión, pero tal vez hay alguna fijación de sesión o predicción disponible.
La aplicación se comparte y, hablando de softs similares a WordPress, puedes imaginar algunas plataformas que comparten muchas instalaciones diferentes, con diferentes módulos y tal vez algún código personalizado. En dichas plataformas encontrará configuraciones que permiten alterar la sal para cada consumidor, hay una razón para eso. Uno de los sitios web podría afectar la seguridad de los demás y la separación limpia puede ser más difícil si las aplicaciones quieren administrar los sitios web todo en uno.

Su aplicación específica puede ser afectada por el entorno, si el almacenamiento de la sesión puede compartirse con algunos scripts de otra aplicación o desde un script en su propia aplicación que ni siquiera haya notado (como estos ejemplos f *** en javascript libs , ¿por qué no suspendiste la ejecución de php en directorios de archivos estáticos?)

Desde este primer paso de compromiso, el atacante podría aumentar potencialmente (y en gravedad):

lea los sellos de sesión y tal vez encuentre qué información debe falsificar para obtener el mismo sello
cree una nueva sesión que contenga un sello de sesión válido para su configuración, y luego use este nuevo identificador de sesión en su aplicación. Su aplicación encontrará el archivo de la sesión y lo aceptará.
modifica una de tus sesiones válidas para modificar el sello de la misma manera

Un simple hash de la estampilla le haría la vida más difícil, pero sería solo una pared para romper, la sal hace que esta pared sea más difícil de romper.

Un punto importante es, a partir de su pregunta, si un chico puede alterar algo en el almacenamiento de la sesión ¿ya estoy de mal humor? . Bueno, tal vez no completamente. Si es lo único que el chroot / separation / securization de las aplicaciones le permite hacer, esta sal será una pesadilla para él.

Y el segundo punto importante es: ¿ debería hacer este nivel de seguridad en profundidad en cada aplicación web? . La respuesta es no. Overengineering es algo malo y puede reducir la seguridad de su aplicación por el simple hecho de que se volvió más difícil de entender y maitin. No necesita complejizar su aplicación si:

tienes un muy buen nivel de separación de almacenamiento de sesión
estás solo en tu servidor, solo una aplicación, y no hay ningún tipo de manejo en varios sitios
el nivel de seguridad de su aplicación es tan débil que hay una inyección de código simple disponible en la aplicación, por lo que no es necesario que el atacante tenga que fijar la sesión :-)

La mayoría tiene sentido, pero el hashing y la salazón no tienen sentido.

Si vincula la sesión a una dirección IP, entonces se vuelve mucho más difícil secuestrar en una sesión. Esto es algo que recomiendo hacer, pero no es necesario que sea estrictamente al respecto. Simplemente puede vincular las primeras tres partes del IPv4 más o menos. La decisión es tuya. Mientras más estricta sea la verificación de IP, más seguro es, pero es menos conveniente para los usuarios.

Y en cuanto a vincular la sesión en función del agente de usuario, eso también puede ser útil. Debe tenerse en cuenta que si trabaja en un canal no encriptado (HTTP por ejemplo), entonces la verificación del agente de usuario es menos útil, ya que también puede ser reproducida por el intruso.

Cuando se trata de salazón y hashing, eso es inútil. No agregan fuerza a sus controles de identidad. Lo único que hacen es complicar tu diseño. Por este motivo, creo que reducen su nivel de seguridad.

Como siempre, algunas reglas a tener en cuenta:

Use identificadores de sesión fuertes. Esto significa usar buenas fuentes aleatorias y asegurarse de que haya suficientes bits.
Ate la sesión a una IP, al menos hasta cierto punto.
Ate la sesión a un agente de usuario, si es posible.
Use SSL / TLS. Sin ella, teóricamente, todos los sistemas de sesión son inseguros.
Asegure su almacenamiento de sesión. Ya sea basado en el sistema de archivos o en la base de datos.

Me imagino que el objetivo de hash esa información de huellas dactilares es el espacio de almacenamiento ya que el hash resultante tiene una longitud fija.

Pero también usar una sal no tiene mucho sentido para mí. Porque, como ya dijiste, dado que esos datos están almacenados en la ubicación de almacenamiento de datos de la sesión, ya tendrías un problema mayor que la fijación / secuestro de la sesión si alguien pudiera obtener esa información.

Muchas personas que no entienden mucho acerca de la seguridad combinan algunos consejos que flotan en Internet con la esperanza de que lo que terminan sea "lo suficientemente bueno". Al vincular el ID de sesión con el UA, se interrumpen las actualizaciones del navegador (que Chrome realiza con bastante frecuencia) y se vincula la movilidad de las direcciones IP (cualquiera con un equipo portátil que usa Wi-Fi) y muchos ISP no tienen asignaciones contiguas. Cualquiera que pueda oler las cookies también puede oler el UA, y probablemente tendrá acceso a la misma dirección IP, ya que obtuvieron la cookie de Wi-Fi inseguro detrás de un NAT.

Lo que probablemente quiera hacer es cambiar la ID de la sesión en un intento de inicio de sesión, que es una forma confiable de evitar ataques de "fijación de sesión" (donde el atacante hace que la víctima cargue http://example.com/?SESSIONID=foo por ejemplo, a través de <img> , espera a que inicies sesión y ahora conoce la ID de la sesión de la víctima). Hay pocas razones para preservar una sesión a través de un inicio de sesión, y puede copiar las pocas cosas que necesitan preservarse (por ejemplo, un carrito de compras).

Puede encontrar una solución plausible aquí: http://shiflett.org/articles/the-truth-about-sessions

Las huellas digitales combaten el secuestro de la sesión. El atacante no solo necesita su session_id , también necesita cualquier encabezado HTTP sensible. Agrega otra barrera para el atacante, aunque se puede superar fácilmente.

El hash está ahí para hacer que los datos sean uniformes. La sal está ahí para oscurecer el proceso de hash, por lo que un atacante no puede generar una huella digital válida para su propia combinación de encabezados HTTP.

Si un hacker está en su sistema de archivos, tiene problemas mayores: D

Puedo pensar en dos casos en los que sería útil:

Cuando los datos de la sesión se almacenan en el lado del cliente. (Como en una cookie.) Por lo tanto, no puedo llevar mi cookie a otra computadora, y me impediría crear mis propios contenidos de cookies. (Bien, este no es un escenario muy probable ...)
Cuando los datos de la sesión se almacenan en algún recurso compartido del lado del servidor (es decir, / tmp) y es vulnerable a la fisgoneo. En este caso, si el snooper puede ver el contenido de la sesión, todavía no podrá falsificar una conexión a esa sesión porque no sabe qué datos entraron en la huella digital.