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.

    Need any further help with this? If so I'll update my answer.

  • The encode() method HTML encodes characters, which is the correct XSS prevention method in this context.

    So if a " character was inserted inside of $str to try and break out of the HTML attribute context, this would be converted to &quot; or &#34; which is the HTML representation.

    Therefore it is not possible to inject script here, assuming encode does 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?

    Yes, as long as the attribute value is correctly encoded and the attribute does not allow script such as `onclick` does. In this example the value is output safely.

  • 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 javascript:. So preventing XSS is not just a question of syntax but also of semantics.

  • 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.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM