¿Se pregunta si existen riesgos o implicaciones de seguridad relacionados con un servidor que devuelve longitudes de encabezado HTTP relativamente grandes (100+)?
¿Se pregunta si existen riesgos o implicaciones de seguridad relacionados con un servidor que devuelve longitudes de encabezado HTTP relativamente grandes (100+)?
Varios firewalls (o IDS, IPS, UTM, NGFW, como quiera que los llamen) tienen límites en la longitud del contenido que analizan en busca de malware (por lo general, alrededor de 10 MB, pero a veces incluso más bajo). Algunos incluyen la longitud del encabezado HTTP en este cálculo. En este caso, el análisis del cuerpo HTTP (que contiene el malware) se puede omitir cuando el encabezado HTTP ya es más grande que el límite de inspección.
El HTTP RFC no corrige la longitud del encabezado, pero al menos indica:
Se encuentran varias limitaciones ad hoc en la longitud de la línea de solicitud en práctica. Se RECOMIENDA que todos los remitentes y destinatarios HTTP soporte, como mínimo, longitudes de línea de solicitud de 8000 octetos.
Eso fue para la primera línea. Para los encabezados que tiene (negrita agregada):
HTTP no coloca un límite predefinido en la longitud de cada encabezado campo o en la longitud de la sección del encabezado en su totalidad, como se describe en la sección 2.5. Varias limitaciones ad hoc en el encabezado individual la longitud del campo se encuentra en la práctica , a menudo dependiendo de la específica Semántica de campo.
Un servidor que recibe un campo de encabezado de solicitud, o conjunto de campos, más grande de lo que desea procesar DEBE responder con un 4xx apropiado Código de estado (error de cliente). Ignorar dichos campos de encabezado serían Aumentar la vulnerabilidad del servidor para solicitar ataques de contrabando. (Sección 9.5).
Un cliente PUEDE descartar o truncar los campos de encabezado recibidos que son más grande de lo que el cliente desea procesar si la semántica de campo es de tal manera que los valores perdidos se pueden ignorar de forma segura sin cambiar El encuadre del mensaje o la semántica de respuesta.
Y en la práctica, el límite de 8000 bytes generalmente también se encuentra en los encabezados.
Cuando se manejan encabezados largos, tener solo un encabezado ignorado es peligroso ( Content-Length:<10,000spaces>42 ). Eliminar un encabezado puede transformar completamente el significado del flujo HTTP (no solo el mensaje actual, sino también otros mensajes segmentados).
Pero la eliminación del encabezado no es el único riesgo, se trataba de un antiguo truncamiento a 5000 bytes por IIS en el pasado. También podría usarse para ocultar una carga útil HTTP activa (como un encabezado Transfer-Encoding: chunked<5000 spaces>, gzip o Content-Length: <4883 spaces>42 donde cualquier actor que elimine el final del encabezado puede interpretar mal la longitud real del mensaje (y tal vez encuentre un nuevo mensaje canalizado que otros actores HTTP no vi).
En su servidor no tanto, es posible que tenga algún software truncado o que no funcione correctamente, pero hay pocos vectores de ataque que utilizan el envío de encabezados HTTP malformados / negativos / creados. Usted debe estar preocupado por recibir esos.
Lea otras preguntas en las etiquetas http