views:

150

answers:

3

How does the XSS (Cross Site Scripting) support provided by ASP.net differs from AntiXss. AntiXss is a microsoft library for securing your site against XSS. Both API looks almost similar and it looks that they can easily be switched from one to another by doing find replace in your code files.

Which one provides more security against XSS? Is it advicable to use the intrinsic support provided by ASP.net?

+2  A: 

There are several differences. First of all the Microsoft AntiXss library uses white list encoding, which means that all characters are encoded, except all characters that are known safe. The standard encoding mechanism of ASP.NET is black list. For HTML encoding for instance, it only encodes 4 characters: <, >, & and " (for instance, it doesn't encode the single quote). Look for instance at this SO answer what can go wrong with this.

Another difference is that basic ASP.NET encoding (using the HttpUtility) is only capable of encoding HTML en URLs. AntiXss also allows encoding HTML attributes and JavaScript text. There is no safe way of doing with in standard ASP.NET.

Steven
@StevenIf am looking for only html and url encoding, then would it be safe to use ASP.net intrinsic support rather than creating a dependency on AntiXSS? What is your advice.
Anand Patel
White list encoding is per definition safer than black list encoding, so it is wise to use the `AntiXss` library. However, when you're using ASP.NET 4.0 you can let the framework use the `AntiXss` library under the covers when you use `HttpUtility.HtmlEncode` method. This saves you from having a direct dependency on the library and allows the whole ASP.NET control stack to use this library. See this blog post for more information: http://idunno.org/archive/2010/04/07/replacing-the-asp.net-encoder-with-antixss.aspx.
Steven
@StevenThanks a lot.
Anand Patel
You should note that implementing the 4.0 class still means you'll have to have the dependency. Whilst the framework does have HtmlAttribute encode and has, as of 4.0, Javascript encode, they're still using a black list rather than a white list. Of course this means the framework versions can be faster, but AntiXSS should be inherently safer.
blowdart
Yes, blowdart is right. `HttpUtility` in ASP.NET 4.0 also contains `HtmlAttributeEncode` and `JavaScriptStringEncode`, but for some reason, the `HttpEncoder` class lacks an `JavaScriptStringEncode` method. Therefore, the javascript encode of the `HttpUtility` will always be a blacklist encoding.
Steven
+1  A: 

One thing you might bear in mind is release cycles; the encoding built into HttpUtility can only be updated when a new version of ASP.NET is released. If someone comes up with an XSS attack that works against HttpUtility the day after it is released, your application is vulnerable until a new version of ASP.NET is released. AntiXSS has a (much) faster release cycle, which means as new attacks appear the team can react to them faster and release an updated AntiXSS that will defend against them.

PhilPursglove
@PhilPursglove Good point.
Anand Patel
A: 

http://blogs.msdn.com/b/securitytools/archive/2009/07/09/differences-between-antixss-htmlencode-and-httputility-htmlencode-methods.aspx

The above link has a very good explanation on the same. I wonder, why I could not get to it before.

Anand Patel
I think this is the most important quote in that blog post: "Anti-XSS library has been designed specially to mitigate XSS attacks whereas HttpUtility encoding methods are created to ensure that ASP.NET output does not break HTML.".
Steven