Tag Archives: request encoding

x-up-devcap-post-charset Header in ASP.NET to Bypass WAFs Again!

In the past, I showed how the request encoding technique can be abused to bypass web application firewalls (WAFs). The generic WAF solution to stop this technique has been implemented by only allowing whitelisted charset via the Content-Type header or by blocking certain encoding charsets. Although WAF protection mechanisms can normally be bypassed by changing the headers slightly, I have also found a new header in ASP.NET that can hold the charset value which should bypass any existing protection mechanism using the Content-Type header.

Let me introduce to you, the one and only, the x-up-devcap-post-charset header that can be used like this:

POST /test/a.aspx?%C8%85%93%93%96%E6%96%99%93%84= HTTP/1.1
Host: target
User-Agent: UP foobar
Content-Type: application/x-www-form-urlencoded
x-up-devcap-post-charset: ibm500
Content-Length: 40

As it is shown above, the Content-Type header does not have the charset directive and the x-up-devcap-post-charset header holds the encoding’s charset instead. In order to tell ASP.NET to use this new header, the User-Agent header should start with UP!

The parameters in the above request were create by the Burp Suite HTTP Smuggler, and this request is equal to:

POST /testme87/a.aspx?HelloWorld= HTTP/1.1
Host: target
User-Agent: UP foobar
Content-Type: application/x-www-form-urlencoded
Content-Length: 14


I found this header whilst I was looking for something else inside the ASP.NET Framework. Here is how ASP.NET reads the content encoding before it looks at the charset directive in the Content-Type header:


if (UserAgent!=null && CultureInfo.InvariantCulture.CompareInfo.IsPrefix(UserAgent, "UP")) {
	string postDataCharset = Headers["x-up-devcap-post-charset"];
	if (postDataCharset!=null && postDataCharset.Length>0) {
		try {
			return Encoding.GetEncoding(postDataCharset);



if (UserAgent != null && CultureInfo.InvariantCulture.CompareInfo.IsPrefix(UserAgent, "UP")) {
	String postDataCharset = Headers["x-up-devcap-post-charset"];
	if (!String.IsNullOrEmpty(postDataCharset)) {
		try {
			return Encoding.GetEncoding(postDataCharset);

I should admit that the original technique still works on most of the WAFs out there as they have not taken the request encoding bypass technique seriously ;) However, the OWASP ModSecurity Core Rule Set (CRS) quickly created a simple rule for it at the time which they are going to improve in the future. Therefore, I disclosed this new header to Christian Folini (@ChrFolini) from CRS to create another useful rule before releasing this blog post. The pull request for the new rule is pending at https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/1392.


Feel honoured to be there again after 8 years: Top 10 Web Hacking Techniques of 2017

I thought I should document this whilst we are still in 2018…

We used to have Top 10 Web Hacking Techniques every year but it suddenly stopped! After having a private conversation with James Kettle in Twitter, he decided to stand up for this and PortSwigger (the company behind Burp Suite) kindly supported it. The full story can be read here: Top 10 Web Hacking Techniques of 2017 – Nominations Open

I was lucky enough to be on the voting panel despite having a nomination (I couldn’t vote for myself obviously). In the end, I felt honoured that my request encoding technique to bypass WAFs came in the Top 10 2017 (#8 to be exact). There were seriously good research works and I recommend you to check them out: Top 10 Web Hacking Techniques of 2017

I have always tried to share with the AppSec community as that also enable me to learn more by reading other people’s work or research. The last time I was on the Top 10 was 2009 for the IIS semicolon bug (remember file.asp;.txt bypass technique on IIS6?) so good to be back (#6): Top Ten Web Hacking Techniques of 2009 (Official) 

Although there has always been discussions on the type of submissions such as techniques vs one time vulnerabilities as well as voting patterns, having a list of web related submissions is always useful and we now have it for 2017!

Rare ASP.NET request validation bypass using request encoding

I had blogged about this in NCC Group’s website. I thought it is the best to add a link to it here as well.

It is possible to bypass the ASP.NET request validation capability when errors are ignored using request encoding techniques. This can be abused to perform stored cross-site scripting (XSS) attacks.

The full article can be read here: https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/september/rare-aspnet-request-validation-bypass-using-request-encoding/

PDF version can be downloaded from: https://soroush.secproject.com/downloadable/Rare_ASP.NET_Request_Validation_Bypass_Using_Request_Encoding.pdf

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!): https://soroush.secproject.com/downloadable/A_Forgotten_HTTP_Invisibility_Cloak_v1.1.pdf

The http.ninja 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 https://drive.google.com/file/d/0B5Tqp73kQStQU1diV1Y0dzd1QU0/view. 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: https://soroush.secproject.com/downloadable/request-encoding-to-bypass-web-application-firewalls.pdf

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 https://github.com/irsdl/httpninja/blob/master/Generic%20Codes/web_request_socket.py

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:

Request encoding to bypass web application firewalls

I “think” I have discovered a “new” technique in bypassing external web application firewalls using request encoding. The idea is very simple but I had not seen this before to be used to bypass any protection mechanisms. Details of this technique has been published via NCC Group’s blog:


This technique was presented as one the methods to mutate the HTTP requests in:

There are loads of other anomalies that can be used to bypass WAFs using webservers behaviour in accepting HTTP requests; my plan is to complete this research and put all the results via the https://http.ninja/ website. Please feel free to contact me via my Twitter (@irsdl) if you have some ideas regarding this.

The unofficial PDF version of this blog post can be downloaded from here:

Almost all the cloud-based WAFs that I had tested could be bypassed using this technique at the time of discovery.