StalkDaily, XSS and you as an ASP.Net Developer

Twitter had been attacked on April 11th, 2009 by a cross site scripting (XSS) worm called “StalkDaily” that was created by a 17 year old.

At the very least this should have made you take a look at XSS vulnerabilities in your website. It should also drive home the point on how easy it is to take advantage of XSS vulnerabilities, as this worm was created by a 17 year old who was bored at home.

So as an ASP.Net developer what is the very least that you should be doing?

1. Know what cross-site scripting is. http://en.wikipedia.org/wiki/Cross-site_scripting Basically any website that accepts user-input and uses that input to create custom web-page content can be vulnerable to XSS. XSS occurs when a malicious user injects code into a web-page that is run from your website. The code can be injected via any input control on your web-page that accepts information from a user. The code then runs as though it came from your web-page and can provide the malicious user login information, etc for for any other user of your website, that visits the page on which the malicious code was injected.

The simplest example of this sort of a XSS vulnerability is when a web-page accepts comments. It is possible for a malicious user to enter javascript code within the comments. When another user views the web-page containing the comments, the code will be run by the users browser and it would open up the user to theft of their information (via posting of the authentication cookie, or just snippets of information from the web-page, to the malicious user’s website).

2. Limit input. The biggest back-door in any website, that makes it vulnerable to XSS are all the fields that allow a user to provide information to your website. Firstname, lastname, comments, etc., if the user can type in information, and the information can make it back to the server – then it has the potential to being misused to inject XSS code into your site.

One simple check that you can do is to type in the following code into a text-input box and see if an alert is shown to you:

<script>alert('you are vulnerable to a XSS hack!');</script>

So, if you need the age of the user, then make sure the input is a number and does not contain alphabets and other special characters. Check for ranges, check for types, check for anything, check for something. Every check that you make, makes your page that much less vulnerable to XSS hacks.

Use the validators (RangeValidator, RegularExpressionValidatior, etc.) on your input fields. Use the Regex class to re-check inputs for containing valid characters and text sequences. Use the Convert class to make sure that input data is of the right data-type, handle any type conversion exceptions.

3. Encode output (especially if it is created from user input).

If the data was at some point entered by a user of your website, then treat is as potentially dirty data. If it is data, then use the HttpUtility.HtmlEncode method remove HTML special characters and re-encode them to the corresponding HTML character codes. If it is a link (url, mailto, etc.) then use the HttpUtility.UrlEncode method to sanitize the URL.

Look for Response.Write and <%= string sequences in your code. These are 2 of the major ways used to output html to the user. Evaluate if HtmlEncode or UrlEncode should be used to sanitize the output.

4. Filter user input

If you must accept potential dangerous user input (such as HTML tags), then see if it would be possible to remove some of the potentially dangerous tags from being part of the input. (Eg: allow tags for bold, underline, italic, and remove iframe, script tags).

It is always better to look for what you would like to allow and remove everything else, then to look for what is banned and to remove them.

5. Make sure that ValidateRequest is turned on for your entire website.

By default your Asp.Net website should be validating user input. This is done via the ValidateRequest value being set to true in either you machine.config file or your web.config file. (ASP.Net, allows you to turn this off on a page-by-page basis, allowing you to evaluate if a certain page does require ValidateRequest to be turned off).

6. Ensure that Asp.Net exceptions are not returned to the user.

Dont make the malicious user’s life easier by returning the entire exception information to them. The exception information frequently contains information (such as table names, field names, etc.) that can make it easier for the user to script code that can take advantage of the XSS vulnerabilities in your website.

Make sure that customErrors mode is set to “remoteOnly” in your web.config. (in addition you could even set it to redirect to a custom error page).

Remember:

Trust nothing, Validate every Input and Sanitize every Output!

Update: Apr 13, 2009: Novologies.com has a good article titled "Securing ASP.Net Applications" that discusses many of the vulnerabilties that can creep into a poorly developed ASP.Net website.

References:

Twitter: http://status.twitter.com/post/95332007/update-on-stalkdaily-com-worm http://status.twitter.com/post/95523421/more-information-about-this-weekends-worm-attacks-can http://status.twitter.com/post/95693986/update-on-worm http://blog.twitter.com/2009/04/wily-weekend-worms.html

How To: Protect From Injection Attacks in ASP.NET How To: Protect From SQL Injection in ASP.NET How To: Use Regular Expressions to Constrain Input in ASP.NET How To: Prevent Cross-Site Scripting in ASP.Net