¿Qué problemas de seguridad hay al leer una cookie con .htaccess?

1

Tengo un sitio web (afición) que se ejecuta solo en SSL (es decir, HTTPS en todo el sitio). El sitio no se ocupa de las finanzas, los números de la seguridad social ni nada de ese nivel de importancia. Sin embargo, me gustaría asegurarlo tanto como sea razonablemente posible. Cuando un usuario inicia sesión, se escriben dos cookies: una cookie almacena la identificación del usuario y la segunda almacena una identificación de sesión. Las cookies están marcadas como Secure y HttpOnly.

Tengo un directorio donde me gustaría que todos los usuarios registrados puedan acceder a los archivos. Me parece que una forma de lograr esto es usar .htaccess en el directorio de claves para ver si hay una cookie de identificación de usuario válida: si es así, conceda acceso, pero si no, redirija a la página de inicio de sesión. De esta manera, no necesito seguir actualizando los valores legales de la cookie o tener una gran sobrecarga en el control de acceso.

Encontré el siguiente código para .htaccess:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_COOKIE} !^.*cookie-name.*$ [NC]
RewriteRule .* /login-error/set-cookie-first.html [NC,L]

y todo esto funciona bien: cuando inicie sesión como usuario registrado (es decir, cuando hay una cookie llamada cookie-name), obtengo acceso al directorio; cuando no haya iniciado sesión, me redireccionarán a la página de inicio de sesión.

Sin embargo, me pregunto: ¿Qué problemas de seguridad he pasado por alto? Por ejemplo, ¿es posible que un atacante cree una cookie con el nombre correcto en el navegador del atacante y luego haga que mi sistema piense que es una verdadera cookie?

    
pregunta RPW 13.02.2013 - 15:58
fuente

2 respuestas

0

Si su servidor otorga acceso solo al ver una cookie con la ID de usuario, entonces el conocimiento de la ID de un usuario es suficiente para obtener acceso. ID de usuario es por lo tanto un secreto valioso. Pero la identificación de usuario no es realmente secreta; a menudo, el ID de usuario es su nombre , que puede considerarse público o, al menos, adivinable.

Lo que necesita es un secreto específico del usuario que, cuando se presenta, otorga acceso, algo que el usuario normal puede mostrar, pero que no puede ser adivinado por personas externas. Esto generalmente se conoce como una "contraseña". La configuración completa es entonces:

  • Hay sesiones . Una sesión es un estado del lado del servidor que es "propiedad" de un usuario. Las sesiones se identifican mediante grandes cadenas de bytes aleatorios (al menos 16 bytes, generados con un PRNG criptográficamente seguro ).

  • Cuando un usuario se conecta por primera vez, no tiene ninguna cookie para enviar. El servidor redirige al usuario a una página de inicio de sesión.

  • Cuando el usuario ingresa su nombre y contraseña, y el servidor ha verificado que la contraseña es correcta, entonces el servidor crea una nueva sesión, con su ID de sesión aleatoria, y la envía ID de sesión como valor de cookie.

  • Para cada página de exploración posterior, el navegador del usuario enviará la cookie de vuelta. Al recibir dicha cookie, el servidor busca en su base de datos la sesión correspondiente. Si el servidor no encuentra una sesión con ese ID, redirige al usuario a la página de inicio de sesión.

  • Para mantener el tamaño de almacenamiento bajo control, el servidor caducará las sesiones (es decir, olvidarse de ellas) que no se han utilizado durante algún tiempo (por lo que el servidor debe mantener en cada sesión una fecha de último uso). / p>

La seguridad de este esquema se basa en el hecho de que los atacantes no pueden "adivinar" una ID de sesión válida: ya que la ID de sesión es aleatoria, el único algoritmo de conjetura es la suerte (los atacantes intentan algunos bytes aleatorios y esperan alcanzar una ID de sesión existente ); el uso de una ID de sesión lo suficientemente grande (los 16 bytes con generación segura) garantiza que la probabilidad de éxito para el atacante sea lo suficientemente baja como para descuidarse.

    
respondido por el Thomas Pornin 13.02.2013 - 17:11
fuente
0

Desea vincular a las ID de sesión y no a las ID de usuario. Las ID de usuario no cambian y no pueden caducar. También se pueden falsificar si se conoce una ID de usuario. Dado que los ID de sesión son aleatorios, no se reutilizan y caducan, es mucho más difícil crear una cookie de sesión válida sin iniciar sesión.

    
respondido por el AJ Henderson 13.02.2013 - 16:05
fuente

Lea otras preguntas en las etiquetas