6

According to OWASP XSS Prevention Cheat Sheet, one should

Strictly validate unsafe attributes such as background, id and name

I understand that background could contain data: urls, and can therefore be exploited even if the content is HTML encoded according to Rule 2.

But why do I have to strictly validate id and name? Is it just because it can be used to inject anchors which could trigger event handlers that were injected by other means? Or is it to prevent DOM-based XSS because of vulnerable scripts that load code from elements using the ID (i.e. shadowing some other element that is present in the page)?

Improve this question

2 Answers 2

Reset to default
3

This is not to prevent double quotes, single quotes or spaces from breaking out of the attribute context, as this is covered by "Aggressive HTML Entity Encoding".

For background, an attack like this is possible:

<body background="javascript:alert('XSS')">

For id and name, these attributes are frequently used as reference points in the DOM.

If an attacker can spoof these reference points, she may be able trick existing scripts into getting and setting values from places other than designed, which may be dangerous depending on the context that is is used.

This also applies to HTML forms where name is used to identify the name/value pair. For example, if a website does not encode a particular form field when it is output, but since the form field is server generated and the form is protected against CSRF by the use of tokens it cannot be exploited by normal means. However, an attacker may be able to entice a user to visit a URL with a parameter that is used in name, containing an XSS payload to execute on submission of the form.

e.g. Normal use:

https://example.com/product?item_name=watch&qty=1

which renders a form

<form>

<input type="hidden" name="watch" value="1" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

And then gets output as

Thank you for buying from Bob's Supplies.

However, an attacker could send a link to the user like so:

https://example.com/product?item_name=shop_name&qty=<script>alert('xss')</script>

As the application is correctly HTML encoding at this point it renders the form as

<form>

<input type="hidden" name="shop_name" value="&lt;script&gt;alert(&#039;xss&#039;)&lt;/script&gt;" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

This then gets output as

Thank you for buying from <script>alert('xss')</script>.

since this page doesn't HTML encode the shop_name parameter because it is trusted and the application framework always takes the first value in case of duplicates. Very contrived, but it was the first thing that fell into my head to demonstrate the point.

Improve this answer
2
  • Hmm, background and JS? I don't get why you referenced <body background="javascript:alert('XSS')"> here, it doesn't even work in any of the 9 major browsers (I tested with IE, Chrome, FF, Opera, Safari, Seamonkey, Avant, Baidu, Torch).
    – Pacerier
    Commented Jan 26, 2016 at 18:22
  • It did used to be an attack when used in the browsers of old, that's why OWASP recommend that it is validated.
    – SilverlightFox
    Commented Jan 26, 2016 at 19:00
0

The text is saying that you need to validate untrusted input when used as any attribute. It is just a restatement of rule 2. Characters such as " could cause big problems.

Improve this answer
2
  • I disagree. Rule 2 is explicitly about "safe attributes" such as "width, name, value, etc", and only requires HTML encoding.
    – 0x89
    Commented May 12, 2015 at 9:54
  • @0x89 - Yes, it is reminding you that you still must check "safe" attributes because, for example, "><script>...</script> even in a safe attribute will allow code injection.
    – Neil Smithline
    Commented May 12, 2015 at 14:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .