User input data, is filtering enough or should it be parsed?

Question

In a webapplication there could be two approaches to migate XSS attacks. All the input data could be filtered (removing all 'bad' data), or the input could be parsed, tokenized and output with only the allowed tags etc.

Which method should be preferred from security standpoint? With either method, what are the gotcha's?

Answer 1

For input validation, I recommend a whitelist approach combined with pass-or-reject. So define what is valid, and accept only valid input, reject everything else.

If you build a rich text editor that sends html to your server, you can use JavaScript to sanitize the input, so that pasting html from Word could end up working. Yet your server won't accept any unsanitized input.

Trying to clean up is subject to being faulty, as that is usually much more complex then just figuring out if input is valid or not.

Whitelisting is essential to good security. You can always to decide to accept more input, while keeping in control. In a blacklist approach, you'll always have to catch up to the latest hack.

For output, see other answers.

Answer 2

I agree with @Jorn's answer about the validation.

However, you're still forgetting a very important step here, and that is output encoding.
E.g. HTML encoding (or Attribute encoding, or Javascript encoding, etc) before outputting anything... In fact, this is arguably even more important than the input validation (arguably, not absolutely, and definitely not in all situations...)
In any event it shouldn't be either/or, its definitely both strict input validation + output encoding.

Now, if you are referring to including "safe" HTML tags in the output (then its not very clear in your question), then you should still encode every thing, and then decode the specific tags you're looking for without any of the tag's attributes.

P.s. If you're referring to a .NET app, MS's AntiXSS (in WPL) provides a .GetSafeHTMLXXX set of methods.

Answer 3

your question "User input data, is filtering enough or should it be parsed?" is more general than the XSS case. I guess, you wanted to be specific for XSS but usually user input can cause much additional exploits like SQL Injection, Path Traversal, XSS... As your question gets more specific on XSS, i would refer to what is already said and go for input filtering and output encoding (always server side!!) with some known countermeasures like the provided by OWASP http://www.owasp.org/index.php/Category:OWASP_PHP_AntiXSS_Library_Project

Still, I would like to point you out that the best way to solve SQL Injection that can be caused by unchecked input is in parametrized queries http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet then if you consider path traversal vulnerabilities, my approach would be some white listing approach.

Hope this helps, Paul

Answer 4

The question is too broad. The best answer is: it depends. It depends upon the format of the user data, and what security policy you're are enforcing.

• For instance, if you are including user data in a SQL query, the best answer is to use prepared statements.

• For instance, if you are including user data -- say, their full name -- in a HTML page, the best answer may be to use output encoding.

• For instance, if you are building a webmail service that allows people to send HTML email, and you want to display an HTML email to the user but only if the email doesn't contain any active content, then the best answer is going to involve parsing and filtering the parsed content.

The best answer depends upon the domain. To get a more useful answer, you're going to need to provide more specifics about the concrete problem you're trying to solve.

Answer 5

I would highly recommend not to reinvent the wheel. Sure, every web-developer must know security basics, but if you have possibility to use robust solution - use it. There are high chances that during implementation of your own filter you'll miss something. Proper input validation is not only about removing bad characters - this is complex topic. Anyway, if you have no other option, then look how other WAF's works. One well-known and robust for PHP applications is http://php-ids.org/. And as for attack vectors, just to remind how "fuzzy" they are - http://heideri.ch/jso/.

Answer 6

Make sure people can't post javascript, I'd just do allowed tags for max security. If you didn't there would be places that people could exploit.