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?

Check this article http://en.wikipedia.org/wiki/Cross-site_request_forgery — Muhammad Akhtar, Aug 21 '11 at 07:04
To all the answerer's, thanks, and yes the linked page does explain things a further, but it was the statement itself that I was questioning. — Zabba, Aug 21 '11 at 07:10

Ofer Zelig · Accepted Answer · 2011-08-21T07:08:00.180

5

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.

edited Aug 21 '11 at 07:08

answered Aug 21 '11 at 07:01

Ofer Zelig

17,068
9
59
93

All the answers are good, marking this one as accepted since it explains the problem clearer. But I don't know, Ofer, why you say "Microsoft is not wrong in their sentence" - the sentence is clearly wrong - maybe I should have also bold-ed the words ***you should** encode...* ? – Zabba Aug 21 '11 at 07:09
3

This guideline is intended for use where your application should accept a legitimate HTML input, for example when providing the user with rich text editing (editing a blog post for example). In that case, technically you should indeed encode client input at the client, else you won't pass the .Net's ValidateRequest barrier. That said - it definitely does not come instead of strong server side validation. And that's MS fault in this article - that they should had immediately emphasize, right after that sentence, that server validation must take place whatsoever. – Ofer Zelig Aug 21 '11 at 07:14

Yahia · Answer 2 · 2011-08-21T07:04:37.423

3

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

edited Aug 21 '11 at 07:04

answered Aug 21 '11 at 06:58

Yahia

69,653
9
115
144

score 1 · Answer 3 · answered Aug 21 '11 at 07:01

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.

score 0 · Answer 4 · answered Aug 21 '11 at 07:05

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.

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

4 Answers4

Linked