For one of my demos last night, I demonstrated how a cookie can be stolen from one site and posted to another site to be recorded for later use. I did this using an ASP.NET 1.1 page. I had believed/assumed as others did that Cross-Site Scripting (XSS) was caught and dealt with in ASP.NET 1.1 once and for all. But, as I learned from Keith Brown last week, there is a bug in ASP.NET 1.1 that allows you to bypass the XSS checking. If you add an URL Encoded null value in the script tag (i.e. <%00script>) you can bypass the checks and retrieve information. Just like with ASP (for now), you still need to HtmlEncode your input (remember -- Do not trust user input. The rule hasn't changed!).
Kirk Allen Evansblogged about this last November: (Update: G. Andrew Duthieblogged informationabout a hotfix for this. NOTE -- As with most hotfixes, there are constraints on its use. The best defense is to use HtmlEncode regardless of the availability of the fix, as well as testing for valid input and rejecting the bad).
ASP.NET 1.1 ValidateRequest Security Flaw
From the DOTNET-WEB list on DevelopMentor:
Monday, September 8th, 2003
Background:
----------
As part of Microsoft's attempts to make it easier for application developers to write secure code, Microsoft has added a new feature, named Request Validation, to the ASP.Net 1.1 framework. This feature is provides out of the box protection against Cross Site Scripting and Script Injection attacks, by automatically checking all parameters in the request and ensuring that their content does not include HTML tags.
Scope:
-----
WebCohort conducted research of this new ASP.Net feature, in order to determine whether it actually provides protection against Cross Site Scripting and Script Injection attacks or not.
The Findings:
------------
The ASP.Net request validation feature has an implementation flaw, which allows an attacker to easily bypass the content restrictions, possibly exposing the application to Cross Site Scripting and Script Injection attacks.
Details:
-------
Our research shows that the feature consists of banning all strings of the form <letter from the content of parameters. Hence the string "<script>", "<img" and even "<a>"are forbidden while strings like "</script>" are allowed. When the server encounters a forbidden string in the content of a parameter it issues an error message to the client.
As a result, WebCohort's Research Team was able to find a simple way to bypass the filtering mechanism. This is done by placing a NULL character between the less-then mark and the first character of the HTML Tag's name. Since this is no longer recognized by the request validation feature as a valid opening tag, it is ignored. However, many browsers, including Microsoft's IE 6.0 disregard NULL characters in their input.
Hence when the string in interpreted by the browser it is interpreted as an HTML tag, effectively yielding a Cross-Site Scripting (or Script
Injection) opportunity.
Exploit:
-------
The exploit is done by simply adding a URL Encoded null character to the request sent to the server. For instance:
foo.bar/search.asp?term=<%00SCRIPT>alert('Vulnerable')</SCRIPT>
Version Tested:
--------------
ASP.Net 1.1
Workarounds:
-----------
Do not rely on this feature for Cross-Site Scripting or Script Injection protection. The only effective method to avoid such attacks is performing HTML encoding within the application code itself.
Vendor Response:
---------------
Microsoft was approached on Thursday, August 21st, and acknowledged the problem the same day. According to Microsoft Security, an all-purpose (non security) software update, due to be released in a few weeks, will solve this problem. Since no preview of this update is currently available, the update has not been tested by WebCohort Research.
