¿Hay alguna manera de saber que una cookie es "Solo HTTP" en la primera solicitud del usuario?

0

Cuando estaba leyendo la sesión artículo de reparación sobre OWASP , pensaba que la única forma de mi servidor Rechazar una cookie configurada por un script malicioso sería para mi servidor saber que el navegador envió una solicitud sin el indicador HTTP-Only. Solo las cookies enviadas al servidor no incluyen nada más que el nombre de la cookie y su valor ... Todos los metadatos se pierden.

Lo que motivó esta pregunta son sus ejemplos # 2 y # 3 donde muestran las URL que se parecen a esto:

http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>
http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>

Personalmente, no entiendo cómo eso podría funcionar de forma remota. ¿Hay algún navegador o servidor que esté roto? ¿Por qué una etiqueta en la URL será aceptada por el navegador o el servidor ?!

Así que creo que saber que el navegador tenía la cookie como HTTP-Only sería útil, pero actualmente no entiendo cómo un pirata informático podría configurar una cookie (que no sería HTTP-Only) asumiendo que no hay ninguna posibilidad. violación de mi código de servidor.

Me imagino que la única forma en que podría funcionar es si el pirata informático fuera a encontrar un XSS en mi código de cliente o servidor. ¿Sería eso correcto?

    
pregunta Alexis Wilke 05.08.2018 - 02:40
fuente

1 respuesta

1

Dado el tipo de ataque al que te refieres, a ... XSS sería el vector más probable para la explotación.

Como mencioné en mi comentario, el ejemplo específico que está mostrando a menudo se usa como un ataque contra las páginas 404 que muestran un fragmento de la URL en el cuerpo de la página sin sanear el contenido HTML. Así que sí ... este es un tipo de ataque XSS perfectamente normal, pero no es el navegador que está roto.

¿XSS sería la única forma de un ataque de fijación de sesión? Probablemente no. Si un atacante logró ejecutar primero un ataque Man-in-the-Middle (MITM) e inyectar su ID de sesión creada antes del inicio de sesión, les permitiría continuar usando esa sesión desde su máquina remota después del ataque.

MITM es más difícil de ejecutar que XSS ... pero aún es posible. Y si el vector para establecer la fijación de sesión fuera MITM, la verificación de HTTP-solo en la cookie sería ineficaz, ya que la cookie podría haber sido modificada por el cable.

La mejor protección contra este vector sería TLS y la educación del usuario para evitar que hagan clic en los errores de certificado.

    
respondido por el nbering 05.08.2018 - 04:08
fuente

Lea otras preguntas en las etiquetas