6

I am going through all the OWASP rules for DOM Based XSS prevention and trying to get a full understanding of each rule. I'm a bit stuck on this rule:

"RULE #2 - JavaScript Escape Before Inserting Untrusted Data into HTML Attribute Subcontext within the Execution Context"

See here:

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#RULE_.232_-_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_HTML_Attribute_Subcontext_within_the_Execution_Context

The problem is that I'm not sure what method to use when "javascript escaping" on the front-end? I know it is not a very likely use case because most front-end developers would generally avoid inserting untrusted data in to an html attribute in the first place, but nonetheless I would like to fully understand what is meant with this rule by understanding exactly what the escape method should be. Is there a simple javascript escape method people typically use on the front-end? Thanks!

EDIT: Other answers I find on stackoverflow all mention html escapers. I'm specifically looking for a javascript escaper and I want to know why owasp specifically uses the term "javascript escaper" if, as some people would suggest, an html escaper is sufficient.

Perhaps the question could also be phrased as "In the context of OWASP's cheat sheet for DOM Based XSS what is the difference between html escaping and javascript escaping? Please give an example of javascript escaping.

mags
  • 590
  • 1
  • 8
  • 25
  • Possible duplicate of [Sanitizing user input before adding it to the DOM in Javascript](https://stackoverflow.com/questions/2794137/sanitizing-user-input-before-adding-it-to-the-dom-in-javascript) – War10ck May 11 '18 at 14:42
  • I think I may have answered my own question. I found a library created by OWASP for all types of client side escaping. It does seem a bit clunky for a small we application. https://github.com/ESAPI/owasp-esapi-js/blob/master/README.md – mags May 14 '18 at 13:27

1 Answers1

3

The escaping needed depends on the context that a value is inserted in. Using the wrong escaping may allow special characters in one context, that aren't special characters in a different context, or corrupt the values.

JavaScript escaping is for values that are inserted directly into a JavaScript string literal via a server-side templating language.

So the example they have is:

x.setAttribute("value", '<%=Encoder.encodeForJS(companyName)%>');

Here, the value of companyName is inserted into a script, surrounded by single quotes making it a JavaScript string literal. The special characters here are things like quotes, new lines, and some unicode whitespace characters. These should be converted to JavaScript escape sequences. So a quote would become \x27 rather than the HTML entity &#x27;. If you were to use HTML encoding then a quote character would be displayed as &#x27; and a newline character would cause a syntax error. JavaScript encoding can be done in Java with encodeForJavaScript, or PHP with json_encode.

It's inserted into a JavaScript value so it should be JavaScript encoded. People are used to HTML encoding attributes but this only makes sense when directly inserting into the HTML, not when using the setAttribute DOM method. The encoding needed is the same as if it were like:

var x = '<%=Encoder.encodeForJS(companyName)%>';

The attribute doesn't need to be HTML encoded because it's not in an HTML context. HTML encoding is needed when the value is inserted directly into an attribute like:

<input value='<%=Encoder.encodeForHTML(companyName)%>'>
fgb
  • 18,439
  • 2
  • 38
  • 52
  • You mention server side escaping. What would a regex look like for client side javascript escaping. I only want to know about client side escaping. Thanks! – mags May 13 '18 at 01:59
  • @mags Client-side escaping would be required if you're building up a HTML string to pass to `innerHTML`. So it's the same as HTML encoding but on the client. You could use something like: https://github.com/janl/mustache.js/blob/master/mustache.js#L60 or use a client-side templating language instead. – fgb May 13 '18 at 15:54
  • I'm specifically asking about javascript escaping. There does seem to be a library for this purpose created by OWASP but it seems very large for client side purposes. I wonder if it is meant for node applications. See here: https://github.com/ESAPI/owasp-esapi-js/blob/master/src/org/owasp/esapi/codecs/JavascriptCodec.js – mags May 14 '18 at 13:22
  • That does the `\x27` etc escapes, so special characters are given with their numeric codes. One reason to do that on the client is when using client-side templates that contain JavaScript. So you have JavaScript that generates more JavaScript, but there are probably alternatives that avoid the need for encoding. – fgb May 14 '18 at 16:28