- HiJacking login sessions (covered in this article)
- Inserting malicious code
- Using resources of your visitors/website
- Inserting links to undesirable websites
- Stealing sensitive information
XSS? It’s just a popup!
FaceBook has been plagued by vulnerabilities, mostly due to it’s popularity. A notable FaceBook XSS flaw was recently discovered in it’s insant messaging JavaScipt handling which could lead to full access to the target’s private messages. Gmail has been susceptible to several stored and reflected Cross Site Scripting attacks over the past few years. A vulnerability was introduced when Google+ integration was rolled out and lead to complete account takeover.
There are many more examples, but that should be enough to scare even the laziest developers.
An XSS Cookie Stealer In Action
The attackflow is simple:
- Find a vulnerability
- Create a payload
- Entice an admin/staff/user to visit the desired URL
- Clone their session or cookie
- Login as victim (Admin?)
Ok so jokes of profit aside, the code required to be deployed on the target site is usually minimal as most of the work happens in a small script used to capture the data. Only two files are required – one to process the data and one to store the logged information (it could be combined into one file, but this is an example on protection… Not skiddie copy/pasta material!).
Introducing “Teh Cookie Monster!”
I spent some time creating a simple cookie logger to demonstrate how this attack could take place. The main script — “cookie-monster.php” — will handle the data collected and “cookie-jar.txt” will simply log the cookies and other information we grab.
The aim of the script was to log all cookies from our target site to a file and allow them to be viewed. The code below is a modified working example that we use internally to help with penetration testing and script hardening.
The line of code above will load our script as a blank image and appear to do nothing to the user. The cookie-monster.php script will grab the visitors cookie along with other data, then save it to cookie-jar.txt for later viewing. This could be expanded to return a valid image.
We have our code and we know what to do, so let’s use Damn Vulnerable Web Application as an example. I have it installed on my localhost and have two accounts – “admin” and “abeon”. I login as “abeon” and create a malicious URL to send to “admin”. This is where the uber-l337 hacking skillz come in handy… We have to make the page attract the admins attention without causing alarm. There are many tactics but an effective one seems to be pretending to report an issue, so kind of break the page but leave it intact enough so as to not arouse suspicion.
Something like this should do…
Yup, that’s right. A long and ugly URL which is only partially encoded and not very well. This is intentional as the user will see the “I BROKE IT” message clearly but will probably miss the script tags. There are many ways to obfuscate the payload such as mixed encoding, internal redirect, URL shortening services, external retrieval and more.
cookie-monster.php will log the information when someone clicks the link and display the saved data. View the cookies by visiting the script’s URL with the mode set as 1 and password as defined at the top of the script:
Protecting Against XSS Attacks
Defending against Cross Site Scripting attacks is handled in a similar way to most other forms of exploitation: validation and sanitization of all data is a must!
The best way to defend against malicious user input is to validate any data that could cause harm, such as checking for a valid email address or phone number, and sanitize any data that is displayed back to the user by converting to benign code.
PHP’s inbuilt htmlentities and htmlspecialchars functions handle both tasks in a very similar fashion. htmlspecialchars converts only 5 characters while htmlentities will convert any HTML characters into their representative counterparts. For this reason, it’s advisable to use htmlentities with both ENT_QUOTES and UTF-8 flags set as below.
Setting ENT_QUOTES will convert both single and double quotes which is essential as both can cause serious problems for security. Using the UTF-8 encoding flag is also very important when using ENT_QUOTES as it defines the encoding used and can help to prevent bypassing using obfuscated code.
A final word of warning:
This example focuses on reflected XSS attacks. A stored XSS vulnerability can be far more damaging as any visitor to the site can be affected – not just those visiting malicious links.
The biggest offender for XSS attacks is without a doubt search forms. Any data a user can alter should be considered a potential risk. Creating validation and sanitization functions through which data can be passed is always easier and more reliable than adhoc coding. There are frameworks and pre-built classes specifically for validation but altering or further developing these can be difficult.