Web14: Problemas de seguridad en el protocolo HTTP

Este artículo presenta algunos problemas de seguridad en el protocolo HTTP , planteados en dos documentos RFC 7230 y RFC 7231. Se hace referencia a ejemplos en el artículo sobre errores específicos de OWASP.

1. Riesgos de factores intermedios

HTTP permite el uso de intermediarios para responder a las solicitudes a través de una serie de conexiones. Hay tres elementos intermediarios comunes: proxy, puerta de enlace y túnel.

Una solicitud o respuesta tendrá que pasar por los puntos A, B y C. Pueden acceder a información sensible que se transmite, como información personal de usuarios u organizaciones. La falta de atención que los intermediarios prestan a la seguridad y la privacidad puede dar lugar a una amplia gama de ataques potenciales.

Los desarrolladores de sistemas y los desarrolladores deben considerar los factores de privacidad y seguridad durante el proceso de diseño, codificación e implementación del sistema.

Los usuarios deben ser conscientes de los peligros de utilizar servidores proxy o puertas de enlace que no sean de confianza.

2. División de respuestas

La división de respuestas (también conocida como inyección CRLF) es una técnica popular de explotación web. El atacante envía datos codificados, en algunos parámetros de solicitud, que luego se decodifican y se repiten en un determinado campo del encabezado de respuesta.

Si estos datos son un símbolo que representa el final de la respuesta y se inicia una respuesta posterior, la respuesta original se dividirá en dos y el atacante controlará el contenido de la segunda respuesta. Luego, el atacante puede realizar otra solicitud dentro de la misma conexión persistente y engañar al destinatario (incluidos los intermediarios) haciéndole creer que esta segunda respuesta es una respuesta a la segunda solicitud.

3. Solicitar contrabando

El contrabando de solicitudes es una técnica que explota las diferencias en el procesamiento de solicitudes por parte de diferentes tipos de servidores para ocultar solicitudes aparentemente inofensivas adjuntas a la solicitud original.

Consideremos el siguiente ejemplo:

Supongamos que una solicitud POST contiene dos campos de "longitud del contenido" en el encabezado con dos valores diferentes. Algunos servidores rechazarán esta solicitud (IIS y Apache), pero otros no. Por ejemplo, SunONE W/S 6.1 utiliza primero el campo Longitud del contenido, mientras que sunONE Proxy 3.6 utiliza el campo Longitud del contenido en segundo lugar.

Suponiendo que el SITIO es el DNS de SunONE W/S, ubicado detrás de un SunONE Proxy, hay un archivo veneno.html ubicado en SunONE W/S. A continuación se explica cómo aprovechar la sugerencia de solicitudes HTTP en función de inconsistencias en el procesamiento entre dos servidores:

[Tenga en cuenta que cada línea termina con un CRLF (“”), excepto la línea 10]

Consideremos lo que sucede cuando se envía una solicitud a W/S a través del servidor Proxy. Primero, el proxy analizará la solicitud de las líneas 1 a 7 (azul) y encontrará dos campos de longitud del contenido. Como se mencionó anteriormente, ignorará el primer campo y entenderá que el cuerpo de la solicitud tiene 44 bytes de longitud. Por lo tanto, trata los datos de las líneas 8 a 10 como el primer cuerpo de la solicitud (de las líneas 8 a 10, los datos tienen exactamente 44 bytes de longitud). Luego, el proxy analizará las líneas 11 a 14 (en rojo) como la segunda solicitud del cliente.

Ahora veamos cómo W/S interpreta los datos anteriores, tal como los reenvía desde el proxy. A diferencia de los servidores proxy, W/S utilizará el primer campo Longitud del contenido y lo interpretará de la siguiente manera: la primera solicitud no tiene cuerpo y la segunda solicitud comienza desde la línea 8 (tenga en cuenta que W/S analizará desde la línea 11 en adelante como el valor del campo de Bla).

A continuación, veamos cómo se devuelve la respuesta al cliente. La solicitud que W/S entiende es “POST /foobar.html” (de la línea 1) y “GET /poison.html” (de la línea 8), por lo que enviará al cliente 2 respuestas con el contenido de la página foobar. html y veneno.html. El proxy entiende que estas 2 respuestas corresponden a 2 solicitudes: "POST /foobar.html" (de la línea 1) y "GET /page_to_poison.html" (línea 11). El proxy almacenará en caché el contenido de la página veneno.html correspondiente a la URL "page_to_poison.html" (envenenamiento de caché). A partir de ahí, cuando el cliente solicite "page_to_poison.html", recibirá el contenido de la página veneno.html.

4. Ataque basado en la ruta del archivo.

Los servidores web suelen utilizar su sistema de archivos local para gestionar la asignación de nombres de archivos en URI a recursos reales en el servidor. La mayoría de los sistemas de archivos no están diseñados para proteger contra rutas de archivos maliciosas. Por lo tanto, el servidor debe evitar el acceso a archivos importantes del sistema.

Por ejemplo, UNIX, Microsoft Windows y varios otros sistemas operativos utilizan “..” como elemento de ruta para representar un directorio un nivel por encima del archivo/directorio actual. Sin el control y la autorización de entrada adecuados, se puede acceder a archivos/carpetas confidenciales del sistema ingresando rutas que apunten a estos archivos/carpetas.

5. Tipos de ataques: Inyección de comandos, Inyección de código, Inyección de consultas

[Los servidores web suelen utilizar parámetros en el URI como entrada para ejecutar comandos del sistema y consultas de bases de datos. Sin embargo, no siempre se puede confiar en los datos recibidos en la solicitud. Un atacante puede crear y modificar componentes en la solicitud (como métodos, campos en el encabezado, cuerpo...), ejecutar comandos del sistema, consultar la base de datos...

Por ejemplo, la inyección SQL es un ataque común en el que el servidor web recibe parámetros en el URI que forman parte de la consulta SQL. Por lo tanto, un atacante puede engañar al servidor web para que ejecute consultas SQL ilegales con el fin de robar o sabotear la base de datos.
En general, los datos enviados por los usuarios no deben usarse directamente para realizar operaciones en el servidor. Estos datos deben pasar por filtros, que definen qué es válido y qué no, eliminando así los datos no deseados.

6. Revelar información personal

Los clientes suelen contener mucha información personal, incluida información proporcionada por el usuario para interactuar con el servidor (como nombre de usuario, contraseña, ubicación, dirección de correo electrónico, etc.) e información sobre las actividades de navegación web del usuario (historial, marcadores, etc.). Al implementarlo, se debe prestar atención a evitar puntos que puedan revelar esta información privada.

7. Revelar información confidencial en el URI

Los URI, por diseño, están destinados a compartirse con todos los usuarios y no se garantiza que sean seguros. Los URI a menudo se muestran en el código fuente del sitio web y se almacenan en marcadores sin mecanismos de protección. Por lo tanto, no será seguro si el URI contiene información sensible, información personal, etc.

Evite utilizar el método GET para enviar información personal al servidor, ya que se mostrará en el URI. Utilice el método POST en su lugar.

8. Revelar información del software utilizado

Los campos User-Agent, Via, Server en el encabezado generalmente brindan información sobre el software utilizado por el remitente. En teoría, eso permite a los atacantes explotar más fácilmente las vulnerabilidades conocidas en este software.