+V4.2 HTTP Message Structure Validation
---+V4.2.1 Verify that all application components (including load balancers, firewalls, and application …
---+V4.2.2 Verify that when generating HTTP messages, the Content-Length header field does not conflict with …
---+V4.2.3 Verify that the application does not send nor accept HTTP/2 or HTTP/3 messages with …
---+V4.2.4 Verify that the application only accepts HTTP/2 and HTTP/3 requests where the header fields and …
---+V4.2.5 Verify that, if the application (backend or frontend) builds and sends requests, it uses …

V4.2 HTTP Message Structure Validation

This section explains how the structure and header fields of an HTTP message should be validated to prevent attacks such as request smuggling, response splitting, header injection, and denial of service via overly long HTTP messages.

These requirements are relevant for general HTTP message processing and generation, but are especially important when converting HTTP messages between different HTTP versions.

1. Prehľad

Názov Štandard
V4.2.1 Verify that all application components (including load balancers, firewalls, and application …

Verify that all application components (including load balancers, firewalls, and application servers) determine boundaries of incoming HTTP messages using the appropriate mechanism for the HTTP version to prevent HTTP request smuggling. In HTTP/1.x, if a Transfer-Encoding header field is present, the Content-Length header must be ignored per RFC 2616. When using HTTP/2 or HTTP/3, if a Content-Length header field is present, the receiver must ensure that it is consistent with the length of the DATA frames.

V4.2.2 Verify that when generating HTTP messages, the Content-Length header field does not conflict with …

Verify that when generating HTTP messages, the Content-Length header field does not conflict with the length of the content as determined by the framing of the HTTP protocol, in order to prevent request smuggling attacks.

V4.2.3 Verify that the application does not send nor accept HTTP/2 or HTTP/3 messages with …

Verify that the application does not send nor accept HTTP/2 or HTTP/3 messages with connection-specific header fields such as Transfer-Encoding to prevent response splitting and header injection attacks.

V4.2.4 Verify that the application only accepts HTTP/2 and HTTP/3 requests where the header fields and …

Verify that the application only accepts HTTP/2 and HTTP/3 requests where the header fields and values do not contain any CR (\r), LF (\n), or CRLF (\r\n) sequences, to prevent header injection attacks.

V4.2.5 Verify that, if the application (backend or frontend) builds and sends requests, it uses …

Verify that, if the application (backend or frontend) builds and sends requests, it uses validation, sanitization, or other mechanisms to avoid creating URIs (such as for API calls) or HTTP request header fields (such as Authorization or Cookie), which are too long to be accepted by the receiving component. This could cause a denial of service, such as when sending an overly long request (e.g., a long cookie header field), which results in the server always responding with an error status.

1.1 Odkazy

1.2 Identifikované požiadavky

1.3 Súvisiace predpisy

2. Identifikované požiadavky

Požiadavky
Zdroj Požiadavka

3. Súvisiace predpisy

Predpisy
Zdroj Regulácia
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.