4

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.

Improve this question
1
  • Need any further help with this? If so I'll update my answer.
    – SilverlightFox
    Commented Sep 28, 2014 at 10:21

4 Answers 4

Reset to default
9

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
2
  • So according to you, wrapping the input data inside double quotes prevents any kind of attribute based attacks. Is that correct?
    – kumar
    Commented Aug 17, 2014 at 20:30
  • 1
    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
    Commented Aug 17, 2014 at 20:37
3

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
0
0

It is almost impossible to inject script here. Especially in real world. You could try use single quote ' to bypass. Might surprise you when doing some ctf.

Improve this answer
-2

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
3
  • 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
    Commented Aug 16, 2014 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
    Commented Aug 16, 2014 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
    Commented Dec 12, 2018 at 13:08

You must log in to answer this question.

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