Questions about Javascript injection

Question

I been reading on asp.net mvc learning site about JavaScript injection and man it is an eye opener.

I never even realized/thought about someone using JavaScript to do some weird ass injection attacks.

It however left me with some unanswered questions.

First

When do you use html.encode? Like do you use it only when you are going to display information that that user or some other user had submitted?

Or do I use it for everything. Like say I have form that a user submits, this information will never be displayed to any of the users, should I be still using html.encode?

How would I do it like I am not sure how to put inside say and Html.TextBox() the html.encode tag.

Second

What happens say I have on my site a rich html editor. The user is allowed to use it and make things bold and whatever. Now I want to display information back to the user through a label. I can't Html.Encode it since then all the bold and stuff will not be rendered.

Yet I can't leave it like it is since what would stop a user to add some Javascript attack?

So what would I do? Use Regex to filter out all tags?

Third

There is also another tag you can use called "AntiforgeryToken" when would you use this one?

Thanks

Edit

Almost everyone says use a "White List" and "Black List" how would I write this list and compare it to incoming values(examples in C# would be nice)?

Answer 1

Good question!

1. For the first answer, I would consider looking here at a previous asked question. As the answer discusses, using HTML Encode will not protect you completely against all XSS attacks. To help with this, you should consider using the Microsoft Web Protection Library (AntiXSS in particular), available from Microsoft.

2. As has already been mentioned, using a list of allowed tags is the best thing to do, leaving others to be stripped out.

3. The AntiforgeryToken token works to prevent request forgery (CSRF) because it gives the user a cookie which is validated against the rendered form field when the page is posted. There's no reason that I am aware of that means that you can't use this in all of your forms.

Answer 2

Use HTML Encode for any data being displayed that has been submitted by a user. You don't need to use it when submitting into the database otherwise you would get odd data like: Simon '&' Sons. Really I don't see the harm to use it on any content written to the page dynamically.

Use a list of allowed tags and discard everything else for your HTML editor. As people said, use a whitelist.

The third one is meant to prevent a Cross-site request forgery attack. You use this to stop people being able to do a POST using a 'stolen' cookie from the user. So you may require a authenticated cookie before accepting a post but a malicious user could take that cookie when a user visits their site and then submit a form to your site claiming to be them.

See here for more: http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx

How to use it: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 3

Always validate the input received against a whitelist. If you use a blacklist you could and probably will come up against encoding issues. Always use a whitelist when validating input.

Do not rely on client side validation to validate the user input. Client side validation is great for helping the user input correct data. But a malicious user will not use this and could bypass the client side validation. Client side validate is should never be considered as a security fix. Using javascript to validate input should not be used. As you can see javascript is very easy to change and modify on any html page. Also javascript can be disabled in browser. So give additional check in your code behind file.

Additionally validate the input every time, not just when the data is initially accepted. For example if you set a cookie, make sure that cookie is the same value and it is correct on each and every request. A malicious user could modify and change the value anytime during the session.

Answer 4

There are various levels of security that can be implemented based on the design considerations of your application.

I would go with the following basic rules:

1. Sanitize all input, removing known malicious sections (for instance, <script> tags in a rich HTML editor). Regex based pattern matching is commonly used for this kind of sanitization.

2. Remove all input that are not in your white-list of allowed values.

3. Encode any HTML before storing in the database and Decode it back when it is being retrieved for display.

Edit:@Phoenix talks about validation in this context so I thought I'd add this. I have said this before and I reiterate: I am not against script based validation. I only caution people not to rely on it expressly. A common design pattern is to validate basic criteria using script based validation and apply rigorous validation on the server side when that data is submitted.