4

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

enter image description here

2 Answers 2

5

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.

3

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) />
<img src=x onerror=alert(document.domain) />
<ımg src=x onerror=alert(document.domain) />

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

3
  • Yes, <, i, and ı can bypass the protection, by will it cause XSS? Feb 13 at 18:31
  • On their own, no. As-is they are not proper HTML, would not render, and the onerror handler would not fire. However, I've tested applications that received the input, did some normalization, and output regular <img tags, which did lead to XSS. The point is that it all depends on the application.
    – lime
    Feb 18 at 14:40
  • 1
    More generally, it's a case for how XSS prevention should be all about encoding outputs properly, rather than trying to stop "dangerous" inputs from reaching the app. A filter like this can add an extra layer of defense, sure, but it can also lull the developer into a false sense of security where they dump raw usually-not-HTML-probably into an HTML context and just hope it was well-filtered on its way in.
    – lime
    Feb 18 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .