Monday, September 8th, 2003
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.
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 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.
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
The exploit is done by simply adding a URL Encoded null character to the request sent to the server. For instance:
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.
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.