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
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.
If you are doing web application security assessments, you probably have seen many APIs that do not have any cross-site request forgery (CSRF) protections other than checking the Content-Type header.
As mentioned in the above URL, bypassing security features using redirection is a common attack vector and it was interesting that this issue had not been reported to Microsoft previously. A similar issue in Adobe Flash had been patched a long time ago (see https://www.whitehatsec.com/blog/flash-307-redirect-game-over/).
I had done a research into the ability of third party websites setting cookies for first party websites across different web browsers. This was published in the NCC Group blog which is available via the following link:
The PDF version of this blog post is also available here: https://soroush.secproject.com/downloadable/Analysis_of_setting_cookies_NCCGroup_blog.pdf
After a few years of finding IIS Short File Name Disclosure vulnerability/feature, I discovered a new method that can work on the latest versions of IIS!
It is a simple trick: If OPTIONS method is used instead of a GET method, the latest versions of IIS will produce a different error message when a short file name is available on the server. The actual bug is exactly the same as the original report and therefore this does not count as a new issue but a new technique.
I have also updated my Java scanner which is accessible via my GitHub repository: https://github.com/irsdl/iis-shortname-scanner/tree/master/
I have successfully tested this scanner on a freshly installed IIS7.5 on Windows 2008 R2 and also on an IIS8.0 on Windows 2012. It seems 8.3 names are still enabled by default… and Microsoft does not seem to be keen to patch this low risk issue after a few years. Well, it is a feature now just like the semi-colon vulnerability in IIS6! ;-)
Test your IIS server and see if it is vulnerable! You may need to add valid headers and cookies to the scanner to be able to scan some special servers.