Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’ve read the pages about xss in OWASP website, 1 2
But i am curious about a question.
Is there any situation where the use of a framework like html purifier or esapy are not possible ? Some type of limitation. If so, I would like to know the situations.
If these situations exist, the manual escaping (output encoding) will be the only alternative to prevent xss ?
Thanks
As soon as you use the data in a non-HTML context those tools are useless. Inlining user-data directly into a javascript block would be a relatively common mistake.
Additionaly any other non-HTML context would open you to similar problems For example: putting the data into some CSS code, in an email address in a SMTP envelope, or using the data in a PDF document.
It is important to understand the injection context and code accordingly. The XSS prevention cheat sheet you link to at OWASP should help to point you towards this method of thinking. Never assume that any “one size fits all” is going to work everywhere. Always think about where you are putting untrusted data and how it can be abused.
Additionally these libraries aren’t perfect and are under constant improvement and bug fixing. For example HTMLPurifier had 2 XSS vuls recently in 2010. Things will also change now that HTML 5 is being more widely supported, as that introduces a number of new injection vectors.