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?
views:
721answers:
3
A:
The AntiXss library also includes Encode methods for things like Javascript or attributes.
SLaks
2010-01-07 17:40:18
+1
A:
White lists are always more secure that blacklist - just think which will be more secure, having a list of all of the people who are not allowed to your party or only allowing in those who are. (Basically blacklists can only handle attacks which are obvious or have been used before).
ternaryOperator
2010-01-07 17:44:52
So, If i have untrusted input from a user that is stored in a datastore and displayed to a user at a later time, do I encode only when I display the data? (Or when I save the data, do I encode it as well)?
2010-01-07 17:54:04
Well generally you should use specific checks before putting stuff into the database (in case of SQL injection) and before display (in case of XSS (e.g. javascript)). Generally a best practice is to specifically name all variables containing any data from the user (e.g. usrName or usrEmail) to prevent accidentally executing user input.
ternaryOperator
2010-01-07 18:21:28
+5
A:
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 whole 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.
Steven
2010-02-24 13:38:25
Actually the range of characters "left alone" by AntiXSS is larger than the ASCII alphabet. We support a few of the more common Unicode/UTF language characters and are looking to expand it to full Unicode 5 support.It's a good point about the HttpEncoder, we're having a sprint meeting today, I'll add that to the features list, as I don't remember seeing it in the codebase (but I've only joined two weeks ago)
blowdart
2010-02-24 13:59:41
I see you're a "Microsoft employee working AntiXSS", but I had to check using Reflector ;-). Of course you're right: The white list is bigger than I thought. Thanks for bringing this up. It would be great if a HttpEncoder implementation could be added to the library, but I couldn't imagine it not be on your list already. Nice to be part of the process ;-)
Steven
2010-02-24 14:35:35
Well it went on the list once you mentioned it. I've only been here a month, and we're doing the first sprint planning for it next week now it's mine, all mine, muhahahahahaha.
blowdart
2010-03-05 17:14:56