Thursday, 25 November 2010

XSS: Cross style scripting attacks in ASP.NET [Examples]

Recently I have been looking at vulnerabilities in ASP.NET applications where XSS attacks are concerned. In recent years, integration with ASP.NET and AJAX has become more apparent as it offers many benefits; including partial page refreshes. However, this opens our applications up to potential attacks, one of which is the main area of focus for this topic: XSS (Cross-style scripting).

Must Read: The XSS Wiki

When creating pages in ASP.NET, you may have stumbled upon the ValidateRequest property of the Page directive before. If not, it's a useful .NET feature that analyses page submissions for potentially unsafe mark up. You can test this yourself by entering <script>alert('Xss Vector!')</script> into a asp.net textbox control and hitting submit on the form. You will receive an exception informing you that the submission is potentially unsafe. Try setting this to false (default is true if not specified) and you'll see that this is no longer picked up by the framework on submit.

So why not leave this set to true for all pages, what's the problem?
1. User's may want to enter markup into a text area control for example.
2. AJAX calls to WebMethod's do not follow this process.
3. Sessions/Cookies/application variables can be hijacked that also do not follow this process.

The three reasons above present a clear reason of why we should add protection to our ASP.NET applications against XSS attacks. Especially as ASP.NET AJAX is becoming more and more common. We have three options for protection against these kinds of attacks.

1. Write your own utility to strip out potentially unsafe markup upon each potentially dangerous call.
2. Include the Microsoft Anti-Cross Site Scripting Library into your solution. This is the same as step 1, but without the "Write your own" bit. It's around 700kb (V1.5).
3. Do not make any of this calls where this becomes an issue [not realistic]


For steps 1 and 2... We need to analyse our code or potential code (I.e. in the design process!) where these issues arise. You refer to the 3 potentially unsafe areas above as a starting point as these area areas where XSS attacks can occur. This Microsoft page gives a good description on how to do this.

Once this areas are known, we can makes all inbound calls safe by stripping out or parsing incoming data using a bespoke tool or Microsoft's Anti-Cross Site Scripting Library.

Here is a typical example where we make an AJAX call to the server and we use Microsoft's library to parse the incoming data. The example also includes a vulnerable option so the two approaches can be compared.

The example can be downloaded here [Requires .NET 3.5]


Useful links:
XSS Cheat Sheet
Test your XSS Attack skills here!

No comments: