Script exploits in ASP.NET - Is setting validateRequest=“true” good advice?

Question

I was reading about ASP.NET Script Exploits, and one of the suggestions is:
(emphasis is mine; and the suggestion is #3 in section "Guarding Against Scripting Exploits " in the web page)

If you want your application to accept some HTML (for example, some formatting instructions from users), you should encode the HTML at the client before it is submitted to the server. For more information, see How to: Protect Against Script Exploits in a Web Application by Applying HTML Encoding to Strings.

Isn't that really bad advice? I mean, an exploiter could send the HTML via curl or something similar, and the HTML would then be sent un-encoded to the server, which can't be good(?)

Am I missing something here or mis-interpreting the statement?

Answer 1

Microsoft is not wrong in their sentence, but on the other hand far from complete, and their sentence is dangerous.

Since by default, validateRequest == true, you indeed should encode special HTML characters in the client in order for them to get into the server in the first place and bypass validateRequest.

But - they should have emphasized that this is certainly not a replacement for server side filtering and validation.

Specifically, if you must accept HTML, the strongest advice is to use white-listing instead of black filtering (i.e. allow very specific HTML tags and eliminate all the others). Use of Microsoft AntiXSS library is highly recommended for strong user input filtering. It's far better than "re-inventing the wheel" yourself.

Answer 2

I don't think that advice is good...

From my experience I would totally agree with your thought and replace that advice with the following:

• all input has to be checked server-side first thing on arrival
• all input that can possibly contain "active content" (like HTML, JavaScript...) has to be escaped on arrival and never be sent to any client till full sanitazion took place

Answer 3

I would never trust the client to send trusted data. As you stated there are simply too many ways that data can be submitted. Even non-malicious users may be able to bypass the system on the client if they have JavaScript disabled.

However on the link from that item it becomes clear what they mean with point 3:

You can help protect against script exploits in the following ways:

Perform parameter validation on form variables, query-string variables, and cookie values. This validation should include two types of verification: verification that the variables can be converted to the expected type (for example, convert to an integer, convert to date-time, and so on), and verification of expected ranges or formatting. For example, a form post variable that is intended to be an integer should be checked with the Int32.TryParse method to verify the variable really is an integer. Furthermore, the resulting integer should be checked to verify the value falls within an expected range of values.

Apply HTML encoding to string output when writing values back out to the response. This helps ensure that any user-supplied string input will be rendered as static text in the browsers instead of executable script code or interpreted HTML elements.

HTML encoding converts HTML elements using HTML–reserved characters so that they are displayed rather than executed.

I think that this is just a case of a misplaced word because there is no way you can perform this level of validation on the client and in the examples contained in the link it is clearly server side code being presented without any mention of the client. Edit: You also have request validation enabled by default right? So clearly the focus of protecting content is on the server as far as Microsoft is concerned.

Answer 4

I think the author of the article misspoke. If you go to the linked web page, it talks about encoding data before it's sent back to the client, not the other way around. I think this is just an editing error by the author and he intended to say the opposite.. to encode it before it's returned to the client.