Cross-Site Scripting (XSS) - Some Examples

Thursday, January 27, 2011

Ben Keeley


Those of us who interact with or manage the results from penetration testing teams all (hopefully!) understand the ramifications when a XSS vulnerability is found.

We may even all understand the differences between a reflected XSS vulnerability and a persistent (stored) XSS vulnerability.

What about those higher up the food chain? Do those who interact with the executives within an organisation fully understand the risks from a XSS vulnerability? Do they paint a realistic picture to those who are ultimately responsible for said website of just what is possible?

A reflected XSS vulnerability is when ‘code’ is injected into a website in such a way so as to deliver a payload or to produce a result on the end users browser. Reflected XSS vulnerabilities are delivered to a victim via various means such as an email causing the user to click on a malicious URL which in itself normally contains the malicious ‘code’.

A persistent XSS vulnerability is one in which the ‘code’ is actually injected into the website itself, and remains for multiple users to be attacked by. For example, placing XSS code within the database that a forum uses would mean anyone who viewed that specific forum or thread would be affected by said code. The URL used to access this forum would not appear malicious…

In this post I’d like to provide some examples of what is possible with a reflected XSS vulnerability, it is in no way an exhaustive list. I created a purposefully weak and simple application that prints (or executes) the text placed in the relevant fields. It uses the GET method which means the code is visible within the browsers address bar…


As can be seen the application is a simple form asking for a Name and CustomerID which are then printed on the next page


Notice that both the Name and CustomerID are in the address bar and now makeup part of the URL…  Lets see if its possible to place a simple Javascript alert in the field?



Notice that the URL contains now the ‘code’ for an alert, and its being executed without restriction.

Time for some fun… Any one remember Rick Astley?


From a PR point of view, an XSS can be very embarrassing. Executed in a certain manner and it could be used to launch a variety of ‘inappropriate’ popup windows which would appear to be from the ‘corporate’ website, it could equally be used to redirect any users accessing the specific URL to a company’s main competition.

From a hacking point of view, XSS can be used for a variety of purposes including the stealing of cookies from user's browsers. Owasp has a great article on XSS, as does Microsoft.

One last example is the embedding of new forms into websites so as to try and steal users legitimate credentials. Now it could be said that vigilant users would see something wrong with the URL, but what about if it was hidden behind a ShortURL? How many of your users would fall for this in that scenario?


Possibly Related Articles:
XSS malware Application Security websites Code Injection Short URL
Post Rating I Like this!
Billy Moore (A bit late to comment on this, seeing as it was made about 5 months ago)

When a link is hidden by a short URL and is not sent by a trusted user, here's a useful website I found.

It expands any short url and shows you any and all redirections it goes through as well as attempted reflected XSS.

I hope this website will get spread around in means of protecting people. It takes about a second to load up the page, a couple to put in the URL and hit enter, and a few to read the results for your safety.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.