Security testing from the cloud

Real-life exploitation of XSS vulnerabilities

Successful exploitation of a cross-site scripting (XSS) vulnerability does not end at <script>alert('xss')</script>.

Showing the real risk of a vulnerability is very important during a penetration testing engagement. It helps the client to better understand the real impact of the problem and makes him fix the problem as soon as possible.

In this post we show you a method to prove your clients the real risk of an XSS vulnerability that you find in the target applications. We will use the XSS Server tool to perform the following actions on a victim user:

  • steal cookies (if they are not httpOnly)
  • retrieve the current page that the victim sees (as the victim user)
  • retrieve a custom page of the vulnerable site (as the victim user)
  • get the current URL of the victim
  • get the current referrer of the victim

We demonstrate this attack on a deliberately vulnerable banking application:

Step 1 – Find a vulnerability in your target application

Let’s say you found the following (unauthenticated) vulnerability in the search form of the application that you tested:<script>alert('xss')</script>


Step 2 – Prepare a unique xss script

Now go to the XSS Server (needs authentication) and create a unique xss script that you will send to the victim. Check the options that you want to be executed by the script in the victim’s browser. In our case, let’s say we want to retrieve the page at the custom url that can be seen only by the admin user.

We obtained the following xss script with an unique id: It contains JavaScript code that will be executed inside the victim’s browser and will perform the desired actions.


Step 3 – Send the malicious url to the victim

Now we can compose a malicious xss url that can be sent to the victim. It can look something like:<script src=></script>

or the shortened version:

At least the shortened version of the url can be sent via email to the victim user (let’s say the application’s administrator) without being flagged as malicious. The link can also be sent in a contact form of the banking application, hoping that somebody on the back-office will read the message and click on the link.

Step 4 – Wait and see the results

Now sit back and relax. When the user will click on the link (and supposing he uses the right browser – preferably Firefox without NoScript addon), our script will be executed and the victim’s data will be sent to the XSS Server. You can see this data by clicking on the red arrow near your script.

In the picture below we can see that the victim has accessed our link on 12th November, at 15:26.


When we press the red arrow, we can see the actual data that was captured from the victim user:


Furthermore, we can see the actual page that the victim saw when it clicked the link. Please note that the victim was already authenticated in his banking application account before accessing the link.



We were also able to access a custom url from the target application  ( as the victim user, which was the logged-in administrator. This page contains ‘sensitive’ information related to the configuration of the application.



Other attack possibilities

While we believe that this demonstration would be enough to prove the real risk of an cross-site scripting vulnerability, the exploitation can continue in order to obtain more data from the user or to attack the application itself. Some other attack possibilities would be:

  • use the application cookies to gain access to the victim’s account
  • use possible CSRF (cross-site request forgery) vulnerabilities to make the victim perform unwanted actions in the application (e.g. add a new user)
  • inject malicious code into victim’s browser in order to exploit browser vulnerabilities
  • inject malicious Java applet, etc


XSS vulnerabilities are high-risk problems which affect web applications that we use every day. This risk must be well understood by web developers and it is our mission as penetration testers to explain the real risk of the vulnerabilities to application owners and developers.

We believe that XSS Server is an easy way to setup an attack scenario that can show the real risk of cross-site scripting vulnerabilities.


4 thoughts on “Real-life exploitation of XSS vulnerabilities

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>