I like django solution - all data substitution are dangerouse, but when you need html you place 'safe' filter, and now you start really thinking safe it or not
For some additional background on context sensitive escaping in HTML, check out OWASP's XSS Prevention Cheat Sheet at http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet. Are there differences with what is recommended there?
So you consider that on large applications, the approach of filtering data when it enters the program is not maintainable. Some dev will forget it, and there is no way to test if all the necessary filters are in place, so you put a big bold filter on the output.
It seems efficient at cleaning the output from xss attacks style, but isn't the remedy worst that the disease ?
If, when it was really necessary devs were forgetting to properly filters inputs, now that there is that filter-on-output system, won't they be even more lazy ?
It seems to me that this approach hardens protection against xss-attacks, and weaken protection against more old school attacks.
@jwilliams: Thanks for the link to the OWASP document, I hadn't seen it before. The different contexts (represented by the individual rules) in that document align well with the ones we targeted, which is great. There are small differences such as handling content in Javascript outside of string literals, CSS in style tags and perhaps more handling of non-quoted attributes but these are all reconcilable. Note that I didn't review the escaping functions themselves.
@olivvv: We didn't write about input validation here as the blog post was already lengthy. We certainly encourage consistent and strong input validation because it helps to prevent not only XSS bugs but also many other correctness and security problems too. There is no reason you can't have both at the same time (input validation and output escaping). That said, in many cases, input validation alone is not a sufficient defense against XSS.
It seems that the inferred filter may be less specific than the actual syntax for the value to be substituted. For instance, the CSS example expects a colour, but the inferred filter will only reject specific unsafe CSS constructs, by the sound of it.
Other than reading the source code, is there any documentation on precisely what each escaping filter does?
Follow
9 comentarios :
I like django solution - all data substitution are dangerouse, but when you need html you place 'safe' filter, and now you start really thinking safe it or not
For some additional background on context sensitive escaping in HTML, check out OWASP's XSS Prevention Cheat Sheet at http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet. Are there differences with what is recommended there?
You guys are a little over my head, but you guys are awesome. Thanks for all the info!
Jack O'Sullivan
Bedroom Sets
Hi
So you consider that on large applications, the approach of filtering data when it enters the program is not maintainable. Some dev will forget it, and there is no way to test if all the necessary filters are in place, so you put a big bold filter on the output.
It seems efficient at cleaning the output from xss attacks style, but
isn't the remedy worst that the disease ?
If, when it was really necessary devs were forgetting to properly filters inputs, now that there is that filter-on-output system, won't they be even more lazy ?
It seems to me that this approach hardens protection against xss-attacks, and weaken protection against more old school attacks.
olivvv
Thanks all for the good comments and information.
@jwilliams: Thanks for the link to the OWASP document, I hadn't seen it before. The different contexts (represented by the individual rules) in that document align well with the ones we targeted, which is great. There are small differences such as handling content in Javascript outside of string literals, CSS in style tags and perhaps more handling of non-quoted attributes but these are all reconcilable. Note that I didn't review the escaping functions themselves.
@olivvv: We didn't write about input validation here as the blog post was already lengthy. We certainly encourage consistent and strong input validation because it helps to prevent not only XSS bugs but also many other correctness and security problems too. There is no reason you can't have both at the same time (input validation and output escaping). That said, in many cases, input validation alone is not a sufficient defense against XSS.
Please roll these changes into the version of clearsilver that is available on appengine:
http://code.google.com/p/googleappengine/issues/detail?id=1363
It seems that the inferred filter may be less specific than the actual syntax for the value to be substituted. For instance, the CSS example expects a colour, but the inferred filter will only reject specific unsafe CSS constructs, by the sound of it.
Other than reading the source code, is there any documentation on precisely what each escaping filter does?
Its here the quality work clean of little else is done at Google. Very good blog post.
Escape-sequences cause so much problem and have do it so long. People patching code from different generations, different projekt and so on.
Very usefull.
IF you want to help remove malware then go here..
http://remove-malware.com/
Publicar un comentario