If I'm using ASP.net controls with requestvalidation, XSS should be prevented right?

Question

Well, we all know there are always XSS vulnerabilities that can be discovered in the future and can undermine ASP.net's default request-validation security.

However, by default, validateRequest is true. Therefore, much of the html values cannot be entered into ASP.net textboxes and other inputs in the first place, correct?

Therefore, although it isn't 100% solid security against XSS, it definitely covers a majority of it right?

I don't believe I would need to do further HtmlEncodes() or a custom plainText() function every time I spit something to ASP.net html (via .Text = ...) from the database, correct?

Answer 1

Input filtering is not the answer to output escaping issues. It is at best a partial and unreliable defence to ward off casual attackers. In my view it is misguided and irresponsible for a framework provider to offer it as a solid defence against XSS issues.

You must HTML-encode any text content you drop into an HTML string. Similarly you must JavaScript-string-literal-encode any text content you drop into a JS string. You must SQL-escape any text content you drop into an SQL query. And so on.

This is totally context-dependent depending on what output format you are creating; it cannot be handled at the input layer where you don't know what the output target format is going to be.

If you're getting any content from a source other than HTTP parameter input and including it in the output then you aren't protected at all; conversely, if you are using HTTP input to create something other than HTML, then your content is unnecessarily mangled. Plus of course you are blocking perfectly valid input—if SO used request validation we would not be able to have this conversation as it would break any time we mentioned <script>.

A wise coder uses an existing library/framework layer to avoid the need to manually call escaping functions, because it's too easy to forget to do it. Hence the advice to use parameterised queries instead of creating SQL from string concatenation. It's the same for HTML: using a well-designed templating language or web controls set will prevent you having to do anything, because the HTML-escaping happens by default.

ASP.NET and Web Forms are partially well-designed in this respect. If you set TextBox.Text=... then yes, the content will be escaped as necessary for you and there's nothing more to do. On the other hand if you set Literal.Text=... it is not encoded, by default (this can be changed with the LiteralMode property). This inconsistency is highly unfortunate.

Answer 2

For the most part you should be protected if you have request validation enabled. Unfortunately, if you need to save markup you will have to strip it first or the validation will throw an HttpRequestValidationException:

See the whitepaper for details: Request Validation - Preventing Script Attacks

Answer 3

I don't believe I would need to do further HtmlEncodes() or a custom plainText() function every time I spit something to ASP.net html (via .Text = ...) from the database, correct?

I would strongly advise against this.

First, ASP.NET request validation doesn't prevent JavaScript or SQL injection.

Second, remember that XSS vulnerabilities occur due to bugs in your code -- for example, code that fails to properly HTML-encode or JavaScript-encode user input. Just because you enable request validation, and ASP.NET prevents some malicious input from getting through, doesn't magically remove the bugs from your code!

Request validation is a defense-in-depth measure that can help prevent your application from being exploited when you make a mistake. Write bug-free code that always properly encodes user input, and you can rest assured that attackers must jump through two hoops before they can compromise your application.