Why use Microsoft AntiXSS library?
When you can simply encode the data using HttpUtility.HtmlEncode, why should we use AntiXss.HtmlEncode?
Why is white list approach better than black listing?
Also, in the Anti XSS library, where do I specify the whitelist?
Answer
You can't specify or alter the white list with the AntiXSS library, which is not strange when you think about it. The AntiXSS library by default encodes all characters that are not in the following range: 0..9a..zA..Z. This set of characters is safe (and therefore are on the white list) and there's no need in encoding them. Please note that the AntiXSS library has different lists for encoding javascript, html and url’s. Please don’t use html encode for url’s, because you’ll have a security hole in your application.
Please note that the white list on HtmlEncode works different than the white list on GetSafeHtmlFragment. With HtmlEncode you say 'please encode every character that's not on the white list', with GetSafeHtmlFragment you say 'please remove all tags and attributes that are not on the white list'.
When you're using ASP.NET 4.0 I'd advice you not to use the AntiXSS library (directly), but simply use the built in mechanisms (such as HttpUtility) to encode Html. ASP.NET 4.0 allows you to configure a HttpEncoder in the configuration file. You can write your own HttpEncoder that uses the AntiXSS library (it’s likely that a future version of the AntiXSS library will contain a HttpEncoder implementation). By doing this, your whole application (and all ASP.NET controls and custom controls) will use white list encoding instead of black list encoding.
ASP.NET 4.0 also introduces a new code block for encoded text. You can use First Name: <%: Model.FirstName %>. However, I personally find <%= HttpUtility.HtmlEncode(Model.FirstName) %> more explicit.