- Los intermediarios, como los cortafuegos, suelen modificar la comunicación de extremo a extremo en Internet.
- Comprender el impacto de estas modificaciones en las normas de Internet pertinentes es esencial para identificar posibles riesgos para la seguridad.
- Recomendamos que las RFC proporcionen directrices claras y rigurosas a clientes, servidores e intermediarios para mitigar estos problemas.
Tradicionalmente, las comunicaciones en red siguen un enfoque por capas, en el que los protocolos de la capa de aplicación, como el Protocolo de Transferencia de Hipertexto (HTTP), deben funcionar de extremo a extremo. Estos protocolos y funciones deben cumplir las normas acordadas (RFC) establecidas por el Grupo de Trabajo de Ingeniería de Internet (IETF).
En la práctica, la comunicación de extremo a extremo suele verse interrumpida por middleboxes,dispositivos intermediosy proxies que mejoran la seguridad y el rendimiento. Un cortafuegos es un ejemplo de middlebox, que bloquea el acceso no autorizado a una red interna, protegiendo a los usuarios de las amenazas externas. Más información sobre las middleboxes.
Comprender cómo afectan estas y otras middleboxes a las cadenas de procesamiento de las comunicaciones y sus correspondientes RFC es esencial para identificar posibles riesgos de seguridad.
Mis colegas, Mahmoud Attia y Marc Dacier, y yo intentamos recientemente examinar cómo los proxies, un tipo común de middlebox (Figura 1), afectan a la conformidad HTTP/1.1, tal como se define en sus correspondientes RFC (ver artículo).
Identificamos 47 normas a nivel de requisitos y comprobamos su cumplimiento en doce proxies populares, incluidas cuatro Redes de Entrega de Contenidos (CDN), componentes clave de la infraestructura que mejoran el rendimiento y la seguridad de la Web. Nuestros hallazgos revelaron tres comportamientos distintos, a saber, algunos proxies:
- Descarta los paquetes no conformes.
- Reenvía los paquetes no conformes tal cual.
- Modifica los paquetes no conformes en conformes.
Los proxies muestran un comportamiento muy incoherente
Nuestros resultados indican que todos los proxies se comportaron de forma similar en 7 de nuestros 47 casos de prueba. Los proxies muestran comportamientos muy incoherentes en los 40 casos de prueba restantes, exponiendo ambigüedades en las interpretaciones del RFC (Figura 3).
Además, ninguno de los proxies siguió una política uniforme para tratar los datos no conformes. Por ejemplo, Cloudflare, una CDN líder, modificó paquetes en 17 casos de prueba, los reenvió sin cambios en 20 casos y rechazó paquetes no conformes en 10 casos.
Además, los proxies demostraron incoherencias entre el tratamiento de las solicitudes del cliente y las respuestas del servidor. La RFC 9112 ordena rechazar o desinfectar los mensajes que contengan caracteres no válidos (CR, LF o NUL). Mientras que todos los proxies rechazaron este tipo de mensajes de cliente a servidor, cinco proxies modificaron las respuestas de servidor a cliente, mientras que siete proxies las reenviaron sin cambios.
Las RFC pueden mejorarse
Nuestro estudio identifica dos problemas importantes con las RFC HTTP/1.1:
- Terminología inadecuada
- Falta de exhaustividad
Las RFC HTTP/1.1 a veces especifican requisitos claros para los “clientes” y los “servidores”, pero dejan ambiguos los “proxies”.
Esto permite a los desarrolladores implementar proxies a su antojo, pero esta flexibilidad también introduce vulnerabilidades potenciales, como el contrabando de peticiones.
Recomendamos que las RFC proporcionen directrices claras y rigurosas a clientes, servidores e intermediarios para mitigar estos problemas. Las normas deben definir explícitamente cómo deben tratar los proxies los datos no conformes, por ejemplo rechazando las solicitudes malformadas como comportamiento por defecto.
De cara al futuro, nos proponemos investigar las reglas a nivel de recomendación además de las reglas a nivel de requisito, analizar las versiones HTTP más recientes (HTTP/2 y HTTP/3) -que introducen mayor complejidad y optimizaciones- y seguir explorando el impacto de las especificaciones RFC y los middleboxes en la conformidad del protocolo. Abordar estas cuestiones contribuirá a unas implementaciones HTTP más seguras en toda la web.
Ilies Benhabbour es estudiante de doctorado y trabaja bajo la supervisión del profesor Marc Dacier en la KAUST. Su investigación se centra en los problemas derivados de la existencia de middleboxes de red.
Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.