Bypassing ASP .NET “ValidateRequest” for Stored XSS Attack

This article introduces script injection payloads that bypass ASP .NET ValidateRequest filter and also details the hit and trial procedures to analyze .NET debug errors. The techniques included in this article should be used when ValidateRequest is enabled, which is the default setting of ASP .NET.

About ValidateRequest: The Microsoft .NET framework comes with a request validation feature which is configured by the ValidateRequest setting. This feature consists of a series of filters, designed to prevent script injection attacks such as HTML injection and XSS (Cross Site Scripting). ValidateRequest is present in ASP.NET versions 1, 2 and 3. ASP.NET version 4 does not use the ValidateRequest filter.

ValidateRequest validates user input and returns false when the following conditions are met:

  1. <a-z     –    A ‘<’ character followed by an alpha character.
  2. <!, </, <?     –    A ‘<’ character followed by a special character.
  3. &,#    –    A special character.

Generally application developers lack proper security training and are time-constrained. So they rely on ASP .NET in-built features to guard their applications. Automated application testing for HTML injection will likely be prevented by the ValidateRequest filters. This ultimately means that tests to ensure that applications have been written following secure programming guidelines can be invalidated.

Classic XSS attack: A general script payload used to test XSS is: <script>alert(‘XSS’)</script>

As we submit this payload to the server, it results in the following error, as .NET considers the submitted request potentially malicious:

Figure-1

Figure 1: Default .NET error page returned when submitting the malicious XSS payload to the server

Understanding filter functions:

Test#1: Submit ‘<script’ as input in text field. It generates a ‘potentially dangerous’ error message. In fact, any alpha (a-z, A-Z) or certain special characters such as exclamation mark (!), or dollar sign ($) after a left angle bracket (<) will generate the same error message:

Figure-2

Figure 2: Left angle bracket followed by alpha or certain special characters results in a ‘potentially dangerous’ error message

Result: The ValidateRequest filter blocks request if any alpha (a-z, A-Z) or certain special characters – i.e. exclamation mark (!) or dollar sign ($) – are supplied after a left angle bracket (<).

Test#2: Submit ‘<XSS STYLE=”xss:expression(alert(‘XSS’))”>’ as input in text field. Again it generates a ‘potentially dangerous’ error message.

Figure-3

Figure 3: ‘<XSS STYLE=”xss:expression(alert(‘XSS’))”>’ results in a ‘potentially dangerous’ error message

Result: The ValidateRequest filter blocks request on matching ‘<XSS STYLE=”xss:expression(alert(‘XSS’))”>’ string.

Test#3: Submit ‘</script>’ as input in text box. The same error page is shown. A simple ‘<’ will not show any error message but a left angle bracket followed by a forward slash (</) will result in the error message:

Figure-4

Figure 4: ‘</’ results in a ‘potentially dangerous’ error message

Now submit ‘<-/’ as input in text box. This time the error page is not shown. It means that this type of payload can bypass the ValidateRequest filter.

Result: The ValidateRequest filter blocks request on matching ‘</’ string but a string like ‘<-/’ can bypass the filter.

Test#4: Now in this test, burp proxy is used to intercept and manipulate the HTTP requests. Instead of using classic payload, an encoded payload is used. Submit ‘script%3Ealert%28%3FXSS%3F%29%3C%2Fscript%3E’ as input in text field. It is nothing but the URL encoded form of our classic XSS payload ‘<script>alert(‘XSS’)</script>’. It results in a ‘potentially dangerous’ error message:

Figure-5

Figure 5: The URL encoded payload results in a ‘potentially dangerous’ error message

Result: The ValidateRequest filter decodes the URL encoded payload and blocks request on matching ‘<a-z’ string.

Test#5: Encode the angle brackets to Unicode. The Unicode equivalent of the classic XSS payload ‘<script>alert(‘XSS’)</script>’ is ‘%uff1cscript%uff1ealert(‘XSS’);%uff1c/script%uff1e’. Submit the Unicode string as input in text field:

Figure-6

Figure 6: The Unicode payload results in a successful XSS attack

Result: The Unicode payload can bypass ValidateRequest filter.

Solution: The above tests show the importance of output sanitization for preventing cross site scripting attacks. Although input validation is present, but can’t protect the application completely.

Microsoft discontinued with ValidateRequest filter in .NET framework version 4.

Advertisements

3 thoughts on “Bypassing ASP .NET “ValidateRequest” for Stored XSS Attack

  1. Gud one to understand easily, shows your effort in it as well. What is the replacement of ValidateRequest in version 4. Should the filter been continued or is it right to discontinue.

    Also would like to know, which would be the better way to pass db query : plain text or unicode?

    • Thanks for the compliments…
      ValidateRequest is actually present in.NET framework 4 also but even if you try to activate the filter, it will not allow you to do so. To activate Validaterequest in .NET 4.0 you have to change ‘requestValidationMode’ value to 2.0 in web.config file.
      Would you please provide more details which kind of db query are you talking about? Are you talking about db queries in a thick client application with 2-tier architecture?

  2. This method will work if .NET grid control is used in the target application and can be used for stored XSS testing only.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s