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. – SilverlightFox Sep 28 '14 at 10:21

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.

| improve this answer | |
  • So according to you, wrapping the input data inside double quotes prevents any kind of attribute based attacks. Is that correct? – kumar Aug 17 '14 at 20:30
  • 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. – SilverlightFox Aug 17 '14 at 20:37

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.

| improve this answer | |

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.

| improve this answer | |
  • 1
    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. – kumar Aug 16 '14 at 6:55
  • 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. – Jeff-Inventor ChromeOS Aug 16 '14 at 9:10
  • 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. – hiburn8 Dec 12 '18 at 13:08

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.