6

In their RULE #1, OWASP suggest that & should be encoded as & before it is inserted into a HTML page. However, in the cases below:

<tag>userInput</tag>
<tag attribute="userInput"></tag>

If I only escape the four characters <, >. ' and ", but not &, is there any payload that could still cause XSS? Or are there any cases where & have to be escaped to prevent XSS vulnerabilitites?

  • Instead of have a single quote ('), I could do &quot, bypassing your filter. – Jeroen - IT Nerdbox May 8 '18 at 5:29
  • 1
    I think that &quot; in userInput could not make attribute closed, or If I have any mistake about it? – z3tt4 May 8 '18 at 6:26
  • 2
    Actually, it's just rule #1 is about element (node) contents. See rule#2 (at least as presented in wikipedia) for encoding text into attributes. And even if & in node content will not cause security concerns, it still would make user-entered text like &lt; show differently that what user entered. – Cthulhu May 8 '18 at 8:36
  • As @Cthulhu says, if you only escape four characters, but not the &, then you can't tell the difference between what was originally & followed by lt; and < that got escaped to &lt;. – TripeHound May 8 '18 at 14:40
3

As the comments say and from your linked document:

Rule #1 is for when you want to put untrusted data directly into the HTML body somewhere. This includes inside normal tags like div, p, b, td, etc.

So your question can be answered with "because you apply the wrong rule for your context".

But to cite the applicable rule as well:

The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.

So, yes, if you consistently and always use quotation marks on attributes, you only need to escape those. But that only needs one slip up and things fall apart, so the general rule is to be more rigorous than absolutely necessary.

  • There are actually two buttons for that: an upvote (the upwards triangle) and an accept (the check mark) if you find the answer helpful and it answered your question:) – Tobi Nary May 8 '18 at 10:57
1

Encoding & to &amp; won't save you from any XSS attacks, but it is necessary for correctly encoding text a user enters into HTML.

For example, if you don't do it, then a user who wants to talk about HTML entities and types the five characters & a m p ; will see the site show their text as & in their browser. A user talking about XSS prevention explaining < to &lt; will see their text rendered on the site as < to <, confusing everyone. Unless you specifically warn users that their posts will be (partially) interpreted as HTML and that they should entity-encode their own posts, it's a thing you should do for correctness, not necessarily security.

-1

&quot; can be harmful, as others suggested.

And with Simple DOM, even CORS rules can be bypassed.

Edit: thanks @Anders, the code I had previously supposed to work did not work.

  • The XSS payload doesn't seem to work when I try it on JSFiddle. Anyway, I'm not sure how it relates to &amp;. – Anders May 8 '18 at 10:27
  • @Anders thanks for telling that.. I supposed it would be probable but it won't... – user9600383 May 8 '18 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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