Cross site scripting is vulnerabilities in web applications that involves injecting valid HTML or scripts in some form or way.

XSS is a very widespread vulnerability (see OWASP TOP 10) on the internet today. It is both easy to eliminate and easy to detect. It is however usually harder to exploit than for example SQL Injection. According to OWASP it is also stated to have moderate impact when exploited, however I find this very debatable. According to Ed Skoudis this vulnerability can have catastrophic effects!

XSS Payload – Presented in 3 different ways

Non-persistent (often called reflected XSS)

A non-persistent XSS  is when you are able to inject code and the server returns it back to you, unsanitized. Often this can be exploited by distributing an (usually innocent looking) URL in some form or way for others to click on. It is important to note that this type of payload is not stored on the system being attacked, e.g. in a database.

This type of a attack can be particular effective when you are dealing with focused attacks against someone. As long as you can make someone click an URL with the necessary payload there is a chance you can gain elevated privileges on the system.

Persistent

If you are able to make the end system store your payload (persist) the attacks becomes much more dangerous very fast. A persistent XSS payload is reflected back to you from the server (not just by clicking a link), usually because the XSS has been stored in a database field or similar. The user is then presented with an attack served by the webserver itself thus making it look legal.

Consider the following input is stored to database and then presented back to you on your profile on the victim site:

This HTML code would give you a input field looking something like this:

If you are able to make the application accept and store unsanitized input, all you have to do is make other users view your profile (or wherever the XSS is reflected back). The payload would then be run on the client system in trust that the victim host was meant to send you the payload.

These kinds of XSS can be not only hard to spot, but very devastating to the victims. Just take a look at Samy worm which we described earlier on this article.

In the early days of the internet this XSS attack was very frequently exploited. Regularly you would see this kind of exploit all over guestbooks, forums, user reviews, chat rooms and so on. The following image describes a usual sight for an old school internet user:

In order to describe the seriousness of this type of attack consider if such an exploit was present in eBay’s auction service. Anytime someone visits your auction they automatically bid on the auction. This type of attack would most likely be trivially easy to exploit unless proper protection is put in place.

DOM-based

Very similar to non-persistent, but where the javascript payload does not have to be echoed back from the webserver. This can often be where simply the value from an URL parameter is echoed back onto the page on the fly when loading using already resident javascript.

Example:

http://victim/displayHelp.php?title=FAQ#

Of course criminals would modify the URL to make it more innocent looking for the untrained eye. The same payload as above just encoded differently:

http://victim/displayHelp.php?title=FAQ#<scri
 #112t>alert(docum
 ent.cookie)</sc
 ript>

It is suddenly much harder to tell it apart from non-harmful parameters.

Two attack vectors

Now that you know the different ways of delivering a XSS payload I’d like to mention a few XSS attack vectors that can be very dangerous.

XSS defacement

Defacement is not a hard feat to accomplish once a XSS exploit is found. If the XSS is persistent as well, it can be a hassle for the sysadmins to figure it out. If you include the this javascript from ha.ckers.org you will produce the following product:

As you can see from the image, this exploit was found on Amazon.com. It is in fact a quite spectacular exploit because it involved the book XSS Attacks: Cross Site Scripting Exploits and Defense which was uploaded to Amazon. The book was made available for preview and thus, because no proper sanitation, the payloads in the book was executed against anyone looking to buy the book.

Cookie stealing and session hijacking

Like in one of the examples above, once you can access users cookies you can also grab sensitive information. Capturing sessionID’s can lead to session hijacking, which in turn can lead to elevated privileges on the system.

Consider a site containing a search field that does not have proper input sanitizing. By crafting a search query with a javascript payload you can gain access to data owned by any user clicking the link.

Sitting on the other end, at the webserver, you will be receiving visitors revealing the users cookie from the victim site. The data is sent through the x parameter where after the double space is the users cookie. Even if the file that is being used is a .GIF file it may still be a programmable script that stores the values in a database. You might strike lucky if an administrator clicks the link, allowing you to steal their sessionID , hijacking their session and allowing you to become administrator of the victim site.

Using techniques like spam email, message board posts, IM messages, Social Engineering Toolkits, this vulnerability can be very dangerous.

If the .GIF file does not exist on the server you are controlling it will simply show up as a 404 file not found, but still revealing the parameter to the file. The attacker can scrape the server logs or use a custom written script to pick up all the session ID’s and proceed to hijack them in order to further exploit the target. This is an example of what it could look like in the server log:

192.168.20.174 - - [20/Aug/2012:09:20:45 +0200] "GET /a.gif?x=security%3Dlow%3B%20PHPSESSID%3D1sbhurqchkd2hk6m35gjg5oef4 HTTP/1.1" 404 503 "http://192.168.20.136/dvwa/vulnerabilities/xss_s/" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.79 Safari/537.1"

The value PHPSESSID is the valuable part in this attack. Using this value as your own may in most cases allow you to act as that person in the respective web-application. Simply by editing your own cookies and replacing the PHPSESSID value with the new value will usually allow you to become someone else.

Exploiting XSS with BeEF

To easy see how XSS can be exploited I recommend trying out BeEF, Browser Exploitation Framework. Once you unpack and run it on a webserver you can easily try spawning a simulation of a victim (called a zombie) where you can very easy try out different XSS payloads. To mention some:

•Steal cookie •Get page HTML •Create alert boxes and command dialogs •Ask the user to reauthenticate •Redirect user to other pages •Integrated with Metasploit! •Send java payload •Enumerate network •Ping sweep network

•Keylogger / event sniffer •Find browser details •Deface page •Rewrite links •Replace videos •Steal clipboard •Detect TOR •Autorun exploits when connected to BeEF •Metasploit AUTOPWN

Injecting XSS when Man in the Middle

If you can become Man in the Middle (MITM) on a target you may very well inject valid HTML code into the packets going through your computer. Although this is a rather new technique to me it is a very interesting and effective way of exploiting users. This type of exploiting users via XSS was known to me via a presentation done on Blackhat by Ryan Linn (web, twitter) and Steve Ocepek (twitter) from Spiderlabs.

Shank is a tool that lets you MiTM and at the same time downgrade any encoding, and finally inject a javascript payload into the HTML header.

By combining Shank with BeEF you have a very interesting attack vector. This type of attack will let you more easily persist hooks on victims. Some of the features this vector allows for can be:

• Poison anyone using HTTP with BeEF hooks
• Persist the hooks when browser changes pages
• Create more subtle and stealthy attacks on the browsers

[important]This question appeared in my security.stackexchange.com feed a while back and I decided to answer it. The link to the original can be found here: http://security.stackexchange.com/a/1373/294.[/important]