How can I bypass double quotes in a attribute based xss attack
The code that I have is:
<input type="text" name="some_name" value="<?php echo CHtml::encode($str); ?>" />
$str is the input data. 'CHtml::encode()' is Yii's way of encoding special characters into HTML entities. Can this be bypassed?
I know it can be broken if I do not put those double quotes around the input. But I do not think just by putting double quotes around will make it unbreakable.
So if a
"character was inserted inside of
$strto try and break out of the HTML attribute context, this would be converted to
"which is the HTML representation.
Therefore it is not possible to inject script here, assuming
encodedoes not have any flaws itself that allows this to happen.
So according to you, wrapping the input data inside double quotes prevents any kind of attribute based attacks. Is that correct?
Within the attribute value (double-quoted) state only the literal double quote
"character (U+0022) allows a proper exit from that state. This is also backed up by the results of fuzzing of characters syntactically equivalent to double quote in HTML attributes.
So if your mitigation technique removes any of those literal characters, you are safe from any XSS that tries to escape from the quoted attribute value.
However, note that some attribute values are interpreted in a special manner like
on…event attributes, style attributes, or URI attributes starting with
If the web site is doing no escaping, validation, or character substitutions, the trivial XSS attack is just:
" /> < script> alert('pawned') < / script>
Which is why every web site should be doing escaping, validation, and substituting or removing dangerous characters.
Thanks. But as I have already mentioned, it uses CHtml::encode() which encodes special characters including single quote. So, the above code injection won't work.
Oh I see. I'd still size check $str. If it's not more than 8 characters, that limits most attacks, because they just won't fit. XSRF unless there's an anti-forgery token.
Limiting string length is completely unnecessary if you actually treat the root problem, which is not output encoding the double-quote in this case. Limiting string length has nothing to do with security at all, people need to stop making weird code decisions that give them a false sense of security.