¿Por qué este ataque de división de respuestas no funciona?

5

Estoy trabajando a través de la aplicación web vulnerable "WebGoat" (versión 5.4) de OWASP, pero me estoy atascando en una de las primeras lecciones que tiene que ver con la división de respuestas HTTP.

He visto todos los consejos y la solución (e incluso todos los tutoriales sobre las interwebs), pero todavía no puedo hacer que funcione.

Incluso he modificado completamente la respuesta de mi servidor web a:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=en
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Graeme</html>
Content-Type: text/html;charset=ISO-8859-1
Content-length: 0
Date: Sun, 28 Jul 2013 20:26:13 GMT

Estoy bastante seguro de que se supone que esto hará que mi navegador muestre "Grezzo", pero en cambio está siguiendo la primera respuesta en lugar de la segunda. Incluso intenté sacar la primera línea "Content-Length: 0", pero no hace ninguna diferencia.

¿Qué está pasando aquí? ¿Me estoy perdiendo de algo? ¿Quizás los navegadores web modernos siempre siguen la primera respuesta en estos días?

    
pregunta Grezzo 28.07.2013 - 22:33
fuente

4 respuestas

10

El componente básico de la división de respuesta HTTP (HRS) que se omite con más frecuencia es el proxy.

HRS no es un ataque entre un servidor web y un navegador, o incluso un navegador y un servidor web.
El ataque es sobre la idiosincrasia de los dispositivos HTTP que cumplen las normas, a saber, el servidor web y el proxy web.
Específicamente, el ataque aprovecha el hecho de que el servidor web ve un conjunto de respuestas (una respuesta), y el proxy ve un conjunto diferente (dos respuestas), y el proxy divide una solicitud a la víctima , y el otro al atacante (o al éter).

Por lo tanto, para probar mejor este ataque, deberías configurar:

  1. servidor web
  2. proxy
  3. navegador de la víctima
  4. cliente atacante (o navegador)

Supongo que te perdiste la parte del proxy ...

    
respondido por el AviD 28.07.2013 - 23:47
fuente
0

No soy un hombre pirata informático), pero creo que el ataque depende del servidor. Por lo tanto, su ataque es exitoso cuando el servidor maneja incorrectamente la solicitud (o maneja incorrectamente la respuesta).

Broswer siempre maneja la primera respuesta (los navegadores más antiguos también manejan la primera respuesta).

Pero este ataque siempre funcionará cuando el servidor coloque alguna variable en uno de los encabezados (por ejemplo: Cookie) Ejemplo simple para entender: Página de carga del cliente que tiene Textarea y botón para enviar solicitud. Cuando el servidor lo solicita, coloca la variable desde Textarea a la cookie (No lo hagas nunca). Así que el cliente puede escribir en textarea estas cadenas:

some data to cookies
Content-Type: text/html
Content-Length: 16

<H1>Hacked</H1>

Entonces, cuando el servidor ponga en cookie esta cadena, la respuesta del servidor sería como esta:

Connection:keep-alive
Content-Type:this server content-type (for example: application/json)
Set-Cookie:qqq="some data to cookies
Content-Length:16  -  your length
Content-Type:text/html - your content type 

<H1>Hacked</H1>

Esto no es un error del servidor, es un error de los programadores que escriben el sitio web.

    
respondido por el Logioniz 29.07.2013 - 20:45
fuente
0

solo asegúrate de usar el retorno de carro. El Codificador de juego de caracteres PHP solo se codifica en %0A , pero debería ser %0D%0A para obtener una nueva línea en la respuesta. Solo si esto se hace, la respuesta se interpreta como HTTP 200 OK (o lo que quieras).

    
respondido por el Thomas 21.06.2014 - 12:38
fuente
-2

También me quedé atrapado aquí por algún tiempo. Resulta que nuestra WebGoat es la versión de Linux. Linux solo usa LF, así que al codificar los parámetros, solo usa% 0a, en lugar de% 0d% 0a.

    
respondido por el Xiang Pan 05.11.2014 - 13:52
fuente

Lea otras preguntas en las etiquetas