Additional notes on “A Forgotten HTTP Invisibility Cloak” talk!

As I could not share the video for my BSides Manchester 2017 talk due to naming a few vendors, I thought the best plan was to explain a few things in a casual blog post. Most of the techniques explained in the presentation were not new although I did not know that initially! In some cases, I was 15 years late to the bypass partei; therefore, I have included links in the references for those who want to read more about them. I should mention that the request encoding technique is particularly the one I am proud of, as I still have not seen it anywhere else.

I think all we need now is the presentation file which has been shared already but here is the PDF version of the original PowerPoint file (to see the slides without SlideShare changes!):

The website is currently linked to a Github repository that contains the Python code I had used to perform the initial tests on my targets. My plan is to update this website with a cheat-sheet of different setups and different test cases. If you have an open source template in mind that can help me with this, please let me know via my Twitter.

So let us begin with the notes about some of these slides (the rests are hopefully self-explanatory and/or mentioned in the references):

Slide #13 (Strange Mutations):

These are not the only methods; some other documented behaviours can be seen in That said, there are probably loads of other test cases that I have not tried yet and will be a great area for research.

Some of the methods explained in this slide could help us bypass protections that were based on the application path or the parameters.

HTTP v0.9 with full header supports on Apache Tomcat is a lovely feature/bug that can confuse loads of WAFs.

Slide #16 (HTTP Verb Replacement):

This method was only useful for those of us who were testing IIS. It was not really necessary to do so in order to bypass the WAFs as shown on the next slides.

Slide #23 (Removing Unnecessary Parts):

The last boundary “- -1- -” could be fully removed if it was a PHP application on Apache or IIS or on Nginx-uWSGI-Django-Python2/3 setup.

Slide #28 (Adding Useless Parts!):

There is just some space characters after the “filename” and before the “=” sign. This is to make it an invalid file upload request and therefore it would remain a normal POST request parameter as before. This mutation on its own can bypass some famous cloud-based WAFs.

Slide #29 – #31 (Changing Request Encoding!):

If charset was used before the boundary, a comma character should have been used as the delimiter between them. Otherwise, a semicolon character should have separated them.

Slideshare has changed the encoded values incorrectly. To see the actual values, you can view them in the PDF file of the presentation.

In order to find more information about this technique, please see the following:

Slide #42 (HTTP Pipelining Example):

If you are using Burp Suite or other web proxies, ensure that the auto update Content-Length feature is disabled.

I, however recommend that to use direct socketing to see the full response as sometimes web proxies do not show it, although you can see it using Wireshark. I have created a simple Python code to do so that you can get it from

Fun fact: HTTP Pipelining can be used to exploit DoS issues, smuggle HTTP requests, or to exploit race condition flaws. However, that is not all it can do! Although I am not giving anybody any ideas, HTTP Pipelining can help you to book your precious online ticket faster than others. This is when you need to send more than one request to book your ticket but the following requests do not use a parameter taken from the previous responses.


I had used the following references when working on my original research (I have added them to the slides as well now):

I also found this afterwards so while not using it as my reference, it is still related and is a good read:

Final Notes:

This talk was a reserved talk and was not planned as a main one; I had been assured that the probability of this happening was about %0.00…01; but hey, even that can win you the lottery sometimes! As one of the first presenters at 9am did not show up on the day, I had to deliver my talk with about 10 minutes notice so I should say thanks to the audience who did not leave the room despite having a different show and had to listen to my random presentation – you are awesome! :)

And here is an interesting Tweet about this:

And yes, BeerSides Manchester was awesome too with some consequences: