Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
add comment

6 Answers

up vote 14 down vote accepted

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.

share|improve this answer
2  
A whitelist approach is definitely the harder of the two from a development standpoint, but I would say it's the way to go for sure. Accept the bare minimum input to start and open it up slowly. –  Doozer Blake Nov 11 '10 at 22:01
1  
When using white listing you have to update the list when you change the application. With black listing you update the list every day a new exploit is published: everyday. –  Hubert Kario Jul 28 '11 at 16:25
add comment

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.

share|improve this answer
2  
+1 for output encoding. Most think that it's enought to validate the input, but neglect to validate the output as well. –  Nikos Steiakakis Nov 12 '10 at 7:21
    
what's the proper way to do this with jstl tags? –  Casey Dec 8 '10 at 2:54
    
@Casey, whats jstl? –  AviD Dec 8 '10 at 8:01
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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/.

share|improve this answer
add comment

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.

share|improve this answer
    
Just limiting the set of tags is not enough to prevent inclusion of malicious Javascript. (Think of, e.g., the ONERROR attribute, CSS styles, etc.) –  D.W. Jan 8 '11 at 2:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.