Bypass Asp.Net 4.6 "A potentially dangerous Request.QueryString value was detected from the client"

Question

I'm testing an application where the application does not handle special characters but request validation in ASP.NET picks it up and throws an exception.

There have been some different ways to bypass this previously like these links show:

http://www.procheckup.com/media/39734/bypassing-dot-net-validaterequest.pdf

https://infosecauditor.wordpress.com/2013/05/27/bypassing-asp-net-validaterequest-for-script-injection-attacks/

http://blog.diniscruz.com/2014/06/bypassing-aspnet-request-validation.html

https://www.whitehatsec.com/blog/by-the-website-vuln-numbers-net-xss-request-validation-bypass/

Is there anything newer that I have missed? The value passed into the q-parameter is printed inside an <h1></h1> tag without any encoding.

Description: ASP.NET has detected data in the request that is potentially dangerous because it might include HTML markup or script. The data might represent an attempt to compromise the security of your application, such as a cross-site scripting attack. If this type of input is appropriate in your application, you can include code in a web page to explicitly allow it. For more information, see http://go.microsoft.com/fwlink/?LinkID=212874.

Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.QueryString value was detected from the client (q="<img").

Version:

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.6.1087.0

Answer 1

As long as a standard charset is being used, there is no known publicly available way to exploit this in HTML context for any common browsers. Source: A lot of research and experience.

Answer 2

Maybe not when it's just immediately reflected, but it depends a lot on the application. I would suggest testing "strange" inputs such as non-ASCII characters, accents, non-printable characters etc, to see whether any of them are removed or normalized (e.g. by the database) before being output.

If that is the case, it could allow you to build a not-really-HTML string that gets past the filter on the way in, but is transformed to valid HTML on the way out. If you look at the source, you'll see the filter is pretty straightforward, it essentially removes null bytes and checks for < followed by a-z, A-Z, !, / or ?:

https://referencesource.microsoft.com/#system.web/CrossSiteScriptingValidation.cs,3c599cea73c5293b

For example, I've had successful bypasses for stored XSS with inputs like the following:

＜img src=x onerror=alert(document.domain) />
<ｉmg src=x onerror=alert(document.domain) />
<ımg src=x onerror=alert(document.domain) />

They use ＜, ｉ, and ı, respectively. Again, your mileage will vary.