HTTP standard conformance tests - HTTP evader

While HTTP seems to be a simple protocol it is in reality complex enough that different implementations of the protocol vary how the behave in case of HTTP responses which are either slightly invalid or valid but uncommon. These interpretation differences is critical if a firewall behaves differently then the browser it should protect because it can be abused to bypass the protection of the firewall.

The following tests are intended to test the behavior of browsers regarding invalid or uncommon HTTP responses. And if there is a firewall or proxy between the test server and the browser then it can be seen how this affects the results and if a bypass of the protection would be possible. More information about bypassing firewalls using interpretation differences can be found here.

Firewall evasion test - Bulk test with virus payload (XHR)

This bulk test tries to transfer the EICAR test virus from the server to the client. This test virus is commonly used for basic tests of antivirus and should be detected by every firewall which does deep inspection to filter out malware. Since this virus itself is not malicious it is safe to run this test.

But, the transfer is done with various kinds of uncommon or even invalid HTTP responses to check if the inspection of the firewall can be bypassed this way. The response from the server will then compared to the expected payload and hopefully all transfers will be blocked either by the firewall or are considered invalid by the browser.

The test uses XMLHttpRequests to issue the request and get the response. In most but not all cases this shows the same behavior as other HTTP requests by the browser (i.e. loading image, script,...). But to verify that an evasion is actually possible with normal download one should use the provided link to actually test the evasion.

Run Test with EICAR test virus payload

Bulk test with innocent payload (XHR)

This is the same bulk test as the previous one but this time the payload is completely innocent. This test can be used to find out the behavior of the browsers itself, i.e. how uncommon or invalid HTTP responses are handled by the browser. It can also be used to check if the use of proxies changes this behavior and if firewalls block innocent payload if it is transferred using an uncommon or invalid HTTP response.

Run Test with innocent payload

Bulk test with innocent Javascript

Contrary to the previous bulk tests this one is not done with XMLHttpRequest but instead it analyzes which responses will successfully be interpreted as JavaScript by the browser, i.e. by using the "script" tag.

Run Test with innocent JavaScript payload

Bulk test with innocent Image

This bulk test will use "img" tags to download an innocent image to check which uncommon responses can be used to load images.

Run Test with innocent image payload

Bulk test with innocent Iframe

This bulk test will use "iframe" tags to download an innocent HTML to check which uncommon responses can be used to load iframes. Warning!: IE and Edge seem to have serious problems with some test cases here and will render the page unresponsive.

Run Test with innocent iframe payload

Non-Bulk tests

The following tests analyze the behavior of browsers in specific cases, like loading an image, loading a script and loading HTML into an iframe. They offer a download for the EICAR test virus. The subtests in these tests all follow the same style: If the browser behaves like expected (i.e. fails or succeeds) the relevant element (IMAGE, SCRIPT or HTML) will turn green, if it behaves differently it will turn red. Yellow is similar successful as green but marks an uncommon behavior. If this uncommon behavior is not implemented (i.e. load of image or script failed) the element will be grey. When trying to load HTML into an iframe it can happen that the iframe stays empty or contains some error message or garbage instead of "HTML". In this case it failed to load the content.

Which behavior is expected can be seen from the header preceding the relevant section of subtests: if it says that the following requests are VALID it is expected that loading succeeds, on INVALID requests it is expected that they fail. In other words: anything turning red is bad and more so if it is for INVALID requests. Because in this case the browser executes the payload even if the HTTP response was invalid which might often be used to bypass firewalls which behave differently.

Variations of server side chunked encoding

Various tests with invalid or uncommon forms of setting or not setting the Transfer-Encoding: chunked header:

Run Test

Variations on content compression

Compression of Content is usueally done with a Content-Encoding header and a value of 'gzip' (RFC1952) or 'deflate' (RFC1951). Most browsers additionally accept RFC1950 compressed data (zlib) if 'deflate' is specified. Some browsers also support compression with the Transfer-Encoding header, which is actually specified in the HTTP RFC, but most browsers don't. Some browsers just guess the encoding, e.g. accept gzip even if deflate is specified. And some browsers accept x-gzip and x-deflate specifications, and some even specifications like "x gzip" or "gzip x". Most browsers accept multiple content-encoding headers, even if it does not make much sense to compress content twice with the same encoding.

Run Test

playing with content-length

These tests look at the behavior if the content-length mismatches the content, e.g. content is short or longer then specified length or contradicting content-lenth headers are given.

Run Test

Various broken responses

This test tries various kinds of broken HTTP responses like

Run Test

no all MIME makes sense for HTTP

Various tests with multipart contents. Most systems do not handle multipart in a special way but Firefox often just uses the last part and ignores the rest while Opera additionally interprets Content-Transfer-Encoding header.

Run Test

RFC822 message transfered with HTTP

This test tries to transfer RFC822 encoded messages with attachments.

Run Test

unexpected range header

These tests try to trick browsers into accepting partial data (and requesting rest) by using Range headers in response, even if no range was requested. It seems, that this does not work - but at least wget tries to automatically resume a broken request with a partial request.

Run Test