July 2013

Evading Security Systems With Dubious HTTP Responses

While HTTP is defined in RFC2616 (HTTP/1.1) the specification does not address every tiny detail. This makes browsers behave similar for the usual HTTP traffic, but they differ in behavior regarding unusual or invalid traffic.

The same interpretation problems can be seen in security systems, e.g. Intrusion Detection Systems (IDS), proxies or firewalls. Thus differences in the interpretation of HTTP leave enough room for circumventing these security systems. This is especially true for systems, which just watch and maybe cut traffic, but not modify the traffic itself. And while active solutions like proxies might rewrite the traffic to avoid misinterpretation, not all solutions do it.

This article highlights some typical interpretation problems.

The following browsers and systems were tested:

Misinterpretation Of Chunked Encoding

With chunked encoding (RFC2616, 3.6.1) the content length is not known in advance, but there will be a content length given for each data chunk and the responses closes with a chunk of length 0.

Chunked Encoding Within HTTP/1.0 Response

Chunked encoding is only defined for HTTP/1.1, thus a "Transfer-Encoding:chunked" header within an HTTP/1.0 response should be ignored. From the tested Web-Browsers Opera, Rekonq and Safari nevertheless interpreted the content as chunked, also the IDS Suricata and Bro and the squid proxy. Google Chrome, Firefox and MSIE instead followed the specification and did not interpret the content as chunked.

Transfer-Encoding "chunked" Variations

If one uses a Transfer-Encoding header of "chunked xx" or "xx chunked" Firefox, Safari, ABP Proxy and Suricata still interpret the content as chunked. Opera does not show this behavior with "xx chunked" but with "chunked xx". Safari instead also interprets "xchunked" and "chunkedx" as chunked and Suricata seems to interpret every value for Transfer-Encoding as chunked, even "chu". Bro does not interpret the content in all these cases as chunked, but strangely adds a newline to the extracted file in these cases.

Folding of Header Line

While HTTP has no line length limitation it still supports folding of header lines over multiple lines similar to MIME. From the checked systems MSIE 8 and 10 are blind to folded lines and interpret the response as unchunked. Rekonq does not understand folding lines either, but considers the response invalid and only reports an error. All other systems have no problems.

Multipart MIME Responses

It is not clear, how multipart MIME messages are useful in the context of HTTP, but there were several attempts made to put them into use:

But Firefox and Opera have some more surprises for us...

multipart/mixed in Firefox and Opera

Both browsers take in some circumstances the last part of a multipart/mixed message as the real content. While this does not work with images in Firefox, it works with HTML displaying inside an iframe or file downloads. In Opera it additionaly works for images and Opera also supports the Content-Transfer-Encoding header, so that the data could be base64 encoded.


If the attacker has full control over the web server serving malware, it should be possible to adjust the payload, so that intermediate security systems will see a different payload than the victim browser.

Corrections, Updates...