4 ms·

So, I've been using this guide as the gold standard : http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet http://www.owasp.org

by keefe 16y ago

So, I've been using this guide as the gold standard : http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%2... what it seems to boil down to is : sanitize user input. In what circumstances is this not sufficient?

geal 16y ago
well, this guid says that you must sanitize user input, but at input time, you may not know where it will come out. So, the solution proposed by this guide is to escape the output. It is another layer of defense: you don't know if you have properly verified the input, but everything you will send to the output will be clean.
- keefe 16y ago
  to me it seems input is anything coming from the user to the database. I was thinking just like, <> -> < > but maybe this is naive or sometimes you require proper html input
Groxx 16y ago
When your sanitizer fails against a previously-untested kind of input, such as the recent problems on YouTube. As audiodude on reddit[1] points out, all you needed was "<script><script>PAYLOAD" to break their sanitizer. I'm honestly surprised this wasn't discovered sooner, odds are someone just got lucky. But yes. Sanitizing user input (assuming a perfect sanitizer) can assure perfect XSS protection, but at a rather severe loss of features (no images / URLs / formatting in your comments). A separate, limited DSL is often the solution for this (BBCode, Markdown, etc), but those sometimes make mistakes too, especially when they're younger. [1]: http://www.reddit.com/r/programming/comments/cluc5/html_injection_vulnerability_in_youtube_comments/ http://www.reddit.com/r/programming/comments/cluc5/html_inje...
- ashearer 16y ago
  If you're going with a DSL anyway, making that language happen to look like a strictly-defined subset of HTML doesn't necessarily reduce its security (plus it allows for a WYSIWYG editor option). But too often what happens next on the back end is an attempt to "sanitize" that input in place and output whatever's left, rather than to fully parse it. That just leads to an arms race between sanitizers and XSS exploiters. Instead, parse the HTML just as you'd have to with BBCode or Markdown. Store it in an internal representation that's only capable of the minimum needed formatting features. (There's no actual HTML left at this stage. It's equivalent to any other DSL.) Then render HTML out of that parse tree, so that every bit of user input is HTML entity-encoded, and everything else (tags and attributes) comes from constants in the program. This can be even more secure than regexp-based DSL translators that build up a result from input in multiple passes, since they tend to lack such a well-defined separation between input text and output HTML.
  - keefe 16y ago
    This makes perfect sense and it's a cogent explanation besides. Do you know of good libraries for this type of work off the top of your head? bonus points for native java

by keefe 16y ago

geal 16y ago

well, this guid says that you must sanitize user input, but at input time, you may not know where it will come out. So, the solution proposed by this guide is to escape the output. It is another layer of defense: you don't know if you have properly verified the input, but everything you will send to the output will be clean.

keefe 16y ago
to me it seems input is anything coming from the user to the database. I was thinking just like, <> -> < > but maybe this is naive or sometimes you require proper html input

Groxx 16y ago

When your sanitizer fails against a previously-untested kind of input, such as the recent problems on YouTube. As audiodude on reddit[1] points out, all you needed was "<script><script>PAYLOAD" to break their sanitizer. I'm honestly surprised this wasn't discovered sooner, odds are someone just got lucky. But yes. Sanitizing user input (assuming a perfect sanitizer) can assure perfect XSS protection, but at a rather severe loss of features (no images / URLs / formatting in your comments). A separate, limited DSL is often the solution for this (BBCode, Markdown, etc), but those sometimes make mistakes too, especially when they're younger. [1]: http://www.reddit.com/r/programming/comments/cluc5/html_injection_vulnerability_in_youtube_comments/ http://www.reddit.com/r/programming/comments/cluc5/html_inje...

ashearer 16y ago
If you're going with a DSL anyway, making that language happen to look like a strictly-defined subset of HTML doesn't necessarily reduce its security (plus it allows for a WYSIWYG editor option). But too often what happens next on the back end is an attempt to "sanitize" that input in place and output whatever's left, rather than to fully parse it. That just leads to an arms race between sanitizers and XSS exploiters. Instead, parse the HTML just as you'd have to with BBCode or Markdown. Store it in an internal representation that's only capable of the minimum needed formatting features. (There's no actual HTML left at this stage. It's equivalent to any other DSL.) Then render HTML out of that parse tree, so that every bit of user input is HTML entity-encoded, and everything else (tags and attributes) comes from constants in the program. This can be even more secure than regexp-based DSL translators that build up a result from input in multiple passes, since they tend to lack such a well-defined separation between input text and output HTML.
- keefe 16y ago
  This makes perfect sense and it's a cogent explanation besides. Do you know of good libraries for this type of work off the top of your head? bonus points for native java