by in
Cross site scripting attacks, commonly called XSS, are becoming more and more prevalent as the power of JavaScript has evolved way beyond simple DOM manipulation. Using the power of embeded JavaScript can be beneficial for an attacker for several reasons including…
- 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!
The common misconception of XSS attacks is that they are benign and of no real significance. Injecting HTML and JavaScript into a page was, once upon-a-time, fairly pointless and meant little more than funky stuff happening to the user inputting the malicious data. The power of JavaScript and now HTML, with offline storage and heavy inbuilt DOM manipulation, has grown exponentially over the past few years.
There are many notable instances of malicious JavaScript deployment being used for exploitation very effectively. Cross Site Scripting attacks have been used against the majority of big social media websites, among others, with notable mentions including…
Twitter suffered an account hijacking exploit, which snared well over 100,000 Twitter accounts. A recent Yahoo XSS exploit lead to many comprimised accounts but the true number is unknown.
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.
Anonymous recently used very simple JavaScript deployment in a very effective manner by inserting a script called “The Hive”, which is a JavaScript based Ddos tool. The aim was simple: take down a well known, and possibly highest value target of all; the Department of Justic. They were successful and it required very little resources compared to previous Ddos attacks.
There are many more examples, but that should be enough to scare even the laziest developers.
An XSS Cookie Stealer In Action
The process of hijacking a user’s session is fairly straight forward but the required code usually takes a little tweaking, depending on the target. The idea is simple: find a point to inject JavaScript, get someone with escalated permissions to visit the page, log their information and replace your current login with theirs.
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?)
- ???
- Profit!!!
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.
File: cookie-monster.php
In order for the above code to work we need to embed some pretty simple JavaScript into our target website…
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:
http://example.com/cookie-monster.php?mode=1&pswd=123-derpy_skid-321There are many ways to edit cookies but browser plugins are the most popular. Edit this cookie is a useful cookie editor plugin for Chrome. Cookies Quick Manager is very similar, but for FireFox.
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.
