An XSS attack in action

An XSS attack in action

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, but not limited to…

  • HiJacking user accounts (stealing cookies)
  • Inserting malicious code
  • Using resources of your visitors/website
  • Inserting links to undesirable websites
  • Stealing sensitive information


XSS? Pah, 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 was the victim of a malicious JavaScript payload which hijacked accounts; it snared well over 100,000 Twitter accounts. FaceBook has been plagued by vulnerabilities, mostly due to it’s popularity — A notable FaceBook XSS flaw was discovered in it’s insant messaging JavaScipt handling which could lead to full access to the target’s private messages.

A recent Yahoo XSS exploit also lead to many comprimised accounts but the true number is unknown.

Gmail has also 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.

The hacking group Anonymous have also used simple JavaScript deployment in a very effective manner by inserting a script called “The Hive” — a JavaScript based DDoS tool. The aim was simple: take down a well known, and possibly one of highest value targets of all; the Department of Justic. They were successful and required very little resources compared to previous DDoS attacks.

There are many more examples. Even those most concerned about security make mistakes. People make mistakes and things get forgotten about. Please don't get defensive if someone tries to help 🙂


An XSS Cookie Stealer In Action

The process of loggins in as another user usually involves hijacking their cookie data. It's fairly straight forward and requires little technical knowledge beyond basic HTML, JavaScript and PHP (or your favourite language).

The idea is simple: find a point to inject HTML/JavaScript, then get someone with escalated permissions to visit the page (admin/staff/valuable user), log their information and replace your current details with theirs.

The attack flow is simple:

  1. Find a vulnerability
  2. Create a payload
  3. Entice admin/staff/user to visit desired URL or embed in a page and wait
  4. Clone their session or cookie
  5. Login as victim (Admin?)
  6. ???
  7. 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 script-kiddie copy/pasta!).


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 is 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 visitor's 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 try it on ourself so we don't break laws and end up in jail! A good test environment to use is Damn Vulnerable Web Application. I have it installed on my localhost and created two accounts – “admin” and “abeon”. I login as “abeon” and create a malicious URL to send to “admin”.

We have to make the page attract the attention of the target without causing alarm. There are many tactics but a common one I see often is to be pretend to report an issue, so partially break the page but leaving it intact enough to not arouse suspicion.

Something like this should do…

A long and ugly URL which is only partially encoded and not very well. This is intentional. There are many ways to hide or obfuscate the payload such as mixed encoding, URL shortening services, internal redirect, external retrieval, etc — this is aimed at fixing the problem, not helping cause it!

cookie-monster.php will log the information when someone clicks the link and display the saved data. View the cookies by visiting the script URL with the mode set as 1 and password as defined at the top of the script:

xss cookie stealer example

There 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 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: all user input should be sanitized and validated!

The best way to defend against malicious user input is to validate any data the public can edit and 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.

Follow me on Twitter, or connect on LinkedIn for more InfoSec rants.

Share this Story:
  • facebook
  • twitter
  • gplus

About Adam Davies

General nerd that started playing with web development in 2001.
Before reporting exploits in websites I broke software protection.