I'm building an iframe, not with innerHTML
, but with createElement
.. I have two untrusted strings that are used:
iframeEl.title = untrustedStr1;
iframeEl.src = `http://example.com/?id=${untrustedStr2}`;
According to the OWASP XSS cheatsheet, the title
attribute is totally safe, so I'm not worried about that.
However, I'm not 100% sure about the iframeEl.src
case.
I'm thinking about the 5 significant characters that typically need to be encoded: <
, >
, &
, "
, and '
and I don't see any way to escape out of the template literal. And I also don't see a mechanism to have untrustedStr2
run as JavaScript. (For example, if untrustedStr2 = 'document.cookie'
, it's interpolated as a string, not via evaluation).
I suppose if untrustedStr2
is a getter method somehow, I could have a problem. But if it's absolutely a string, this is safe and I don't need to encode, not even for the 5 significant characters. Is that right?
When working with the DOM, there are no html encoding issues in any element properties. The characters
<
,>
,&
,"
, and'
do not need escaping.However, you still need to deal with the semantics of the respective attribute. While
title
is just a plain string that's not used for anything but displaying tooltips, others are not safe:on…
event handlers contain javascript code. It's a bad practice to assign strings to them anyway, but if you do, interpolating values must follow javascript escaping rules.⇨ Rule #3
style
properties contain CSS rules which need their own escaping.⇨ Rule #4
src
orhref
attributes are urls that the browser will load at some point. Those definitely are sensitive, and when interpolating values into urls you need to follow URL encoding rules.⇨ Rule #5
In your particular case, if you fail to url-encode the
untrustedStr2
, the attacker may send arbitrary query parameters or fragments toexample.com
. This is not a security issue in itself if example.com isn't susceptible to reflected XSS (the attacker may send the same link to the user via other channels), but it is broken functionality (undesired behaviour), but still it's your page endorsing the linked content.So if
untrustedStr2
is meant as a value of theid
URI query parameter, you should definitely use