Cross site scripting (XSS) can be a rather complicated vulnerability to get a grasp on, so let’s take some time to explore it. The general idea is that a user, whether it be a be a random visitor from the Internet, or a registered user (think forum), can get code onto a website, which then gets run in a victim’s browser.
What Can You Do With An XSS Vulnerability?
In general, anything, but there are two main types of attacks: cookie stealing, and client side exploitation.
- Cookie Stealing:
- First let’s start off with: what is a cookie. When you successfully log in to a website, the server issues you a unique identifier. This identifier is what we call the cookie and looks something like this: website%7C2301209614%7Cfc9be9fe70fc460d76c352de15de6bc2 Why do we go through all this nonsense? The cookie issued is unique per session (from log-in to log-out) so it is not permanent like a password. It is also unique to that server, and generated random. This offers the most amount of protection for a user.
- Client Side Attack:
- When a malicious person tries to exploit vulnerable software on an unsuspecting user’s machine. Typically the malicious user is trying to exploit the browser (Internet Explorer, Mozilla Firefox, Google Chrome), a browser plug-in (Adobe Flash, Java) or a program which can be launched from the browser (Adobe Acrobat).
Types of XSS
There are three types of xss: persistent, reflected, and DOM based. For simplicity, we will look at persistent and reflected.
- Persistent xss are attacks which are saved on the vulnerable server. A good example of this would be someone writing a malicious forum post. Once the user hits [Submit], the content is saved on the server. Another example is someone commenting on a blog post (which is exactly why I have comments disabled here). These types of attacks are not visible to a normal user, and the only way to identify the exploit is to view the source code of vulnerable website.
- Reflected xss are those which are not stored on the server, and are sent to the victim directly. This is usually done through email, chat, or other malicious link. The link will contain the exploit code to run in it. These are usually more obvious to the user as they can be rather long links to click.
Technically, How Does Cookie Stealing Work
- The Attacker goes to a website and identifies an XSS vulnerability.
- The attacker Submits their malicious code (which is not visible to the user).
- Normal users go visit the website that contains the malicious code on it from the attacker.
- The malicious code is executed by the unsuspecting user’s browser. It calls back the attacker (or other computer the attacker has access to). The attacker is then able to steal the cookies.
- The attacker is now able to use the stolen cookies to log-in as the victims.
Technically, How Does Client Side Exploitation Work
- Follow the Cookie Stealing example right above this up through step 4.
- Instead of stealing the cookie (which could also be done), the attacker now has the users load exploits which can take control of the normal user’s (victim) computer.
From my post Getting Pwnd by a Chinese 0day:
So, how can we stop this from happening? First, keep in mind we are dealing with an 0day, so there is no patch available. For a XSS based attack, we need to prevent scripts from running, especially ones from untrusted websites. To accomplish this in Mozilla Firefox, simply use No Script. In Google Chrome, you need to dig into the options. Click the wrench icon in the top right corner. Select Preferences > Under The Hood > Under Privacy, click Content Settings…, select Java Script. You can now set your options. Disabling all java scripts may make certain websites (almost all) look funny/different. You will have to allow sites to run some java script, but the key is to only run java script for the page your are going to. For example, if you go to www.myfavoritesite.com, No Script may tell you that three different sites want to run java script: myfavoritesite.com, aMALICIOUSsite.com, and googleTracker.com. In this case you would only want to run myfavoritesite.com since that is the page you are at.
I just couldn’t resist! We can look at a few live examples of sites vulnerable to xss. To keep these examples safe, I will not steal cookies or run client side exploits. Instead I will just add content to the site, or use pop-up boxes as proof of concept.
Example 1: Brightroom.
This company takes photos at race events and sells them to participants. That money does not go to website security though as I identified this issue on 6/24/2010.
Type: Reflected XSS
Exploit From Link:
<h2>Proof of XSS via cactus</h2> <img src="http://visopsys.org/andy/cat/uploaded_images/182boner-714406.jpg" alt="" />
Keep in mind we can control what is shown here, so we could make it anything. Yes I am aware that I am actually displaying HTML injection, but it is also vulnerable to XSS.
After creating this post I found out that I was not the first to identify this vulnerability. I found this a month after it was reported to xssed.com, but kept it amongst friends as a joke.
Example 2: vBulletin.
This vulnerability is a few years old, but identifying a Stored XSS ethically/legally is difficult. The video shows quite a bit of information on everything.
Type: Stored XSS
www.xssed.com is a site dedicated to tracking/identifying sites that have XSS vulnerabilities. It is quite funny to go through some of the sites that have been identified (McAfee, PayPal, eBay, American Express).