Wondering if there are any security implications / risks involved with a server returning relatively large (100+) HTTP header lengths?
3
-
It'll depend on the contents of the header, you might be leaking too much information?– WhomeJan 14, 2016 at 4:25
-
The information in the headers are pretty much useless from what I see. Multiple Set-Cookies on client side.– user987654321Jan 14, 2016 at 4:28
-
"pretty much useless" - no. Most web applications use cookies as a surrogate authorization. A third party who has access to your cookies has access to your account. They can also reveal a LOT about your infrastructure - a good starting point for planning an attack.– symcbeanJan 14, 2016 at 13:41
Add a comment
|
3 Answers
Several firewalls (or IDS, IPS, UTM, NGFW - whatever you call them) have limits on the length of content they analyze for malware (usually around 10MB, but sometimes even lower). Some include the length of the HTTP header into this computation. In this case the analysis of the HTTP body (containing the malware) can be bypassed when the HTTP header is already larger than the inspection limit.
answered Jan 14, 2016 at 5:50
-
1Apparently on June 9 fortiguard updated their IPS definitions for HTTP.Server.Authorization.Buffer.Overflow to limit the length of an authorization header - See: fortiguard.com/encyclopedia/ips/12351 We had to guess at what length our authorization header could be due to lack of documentation. Ended up being okay at around 350 characters.– dykstradJun 26, 2020 at 18:40
The HTTP RFC does not fix the header length but is at least stating:
Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
That was for the first line. For headers you have (bold added):
HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole, as described in Section 2.5. Various ad hoc limitations on individual header field length are found in practice, often depending on the specific field semantics.
A server that receives a request header field, or set of fields, larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 9.5).
A client MAY discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
And in practice the 8000 bytes limit is usually found on headers also.
When handling long headers, having just one header ignored is dangerous (Content-Length:<10,000spaces>42). Removing one header can tranform completly the meaning of the HTTP stream (not only the current message, but also other pipelined messages).
But header removal is not the only risk, they was an of an old truncation at 5000 bytes by IIS in the past. It could also be used to hide an active HTTP payload (like a Transfer-Encoding: chunked<5000 spaces>, gzip header or Content-Length: <4883 spaces>42 where any actor removing the end of the header may badly interpret the real message length (and maybe find a new pipelined message that other HTTP actors did not saw).
In your server returning not so much, you may have some software truncating or not working correctly, but there are few attack vectors using sending malformed/negative/crafted HTTP headers.. smuggling/splitting/poisoning .. you name it. You should be worried about receiving those.
