According to a research conducted by PreciseSecurity, in 2019, nearly 40% of All Cyber Attacks were performed by using cross-site scripting (XSS).
In this post, you will learn more about this vulnerability. How it can be used to impact real systems and have some guidelines on how to deal with user data. Covering all possible attack vectors that stem from XSS is not in the scope of this article, but I’ll leave you with some links for you to learn more about this topic.
An XSS attack takes advantage of 2 main points of how the internet and browsers work:
This kind of flaw has 2 main categories, Stored and Reflected.
Where the vulnerability is permanently stored on the target servers. For example, if we can insert a script in a comment section, everyone seeing the comments will be attacked.
Where the vulnerability comes from an input, for example, a GET parameter. If we can get our victim to click on a malicious link with a GET parameter, that is being printed back on the webpage, we have a successful attack.
Ok, security is fun to theorize about, but what’s the risk? As always, it depends on the type of web application, the existence of other existing vulnerabilities, the application visibility and lots of other things. So it can range from the attacker being able to redirect users to other pages, or to being able to steal authentication tokens from highly privileged users, rendering the login form useless.
Now you may be thinking: “Yea yea, that’s cool and all, but… give me real examples”.
The result wasn’t what he anticipated, as this turned into a worm, as it grew exponentially. This was the first documented case of an XSS worm and it infected over 1 million profiles in 24 hours.
Ok, but that’s an old platform, it should be solved by now, right?
Learn more here.
We now know how this works, the risks and some companies that were affected by it, how do we exploit it?
Calm your horses, trying XSS attacks is part of a PenTest work that’s subjected to a prior agreement with the owners of that software. If you’re interested in trying to exploit an application that doesn’t belong to you make sure you have a PenTest request signed first. There are companies that have an active bug bounty program and if followed, you are allowed to test their systems.
Here are some lists of companies that you can try this on:
So let's assume you are developing a web app and want to see if you’re vulnerable. The easiest way to do it is to run something link OWASP ZAP to crawl and test it for you.
If you're successful, you’ll see something like this:
If not, maybe your application is already escaping some characters and if so we need to test evasion methods depending on where your input is being inserted, see a comprehensive list of evasion methods here: https://owasp.org/www-community/xss-filter-evasion-cheatsheet
To exploit a reflected vulnerability we can search for places on our application where we print a message that is sent through a get parameter and test it using something like this:
This, if successful, will return the same result as the last attack.
Remember that it’s possible to escalate this vulnerability, depending on your application, but that will require you to use your imagination.
A good place to start is to read these guidelines: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
But I know that’s tedious for most developers, so the number one rule is to NEVER TRUST USER INPUT.
If you have user input and want to print it back on the webpage, always sanitize it (encode it and validate it) and whitelist some terms if needed only for example <br> or <p> tags.
Every web language already has some implementation of functions to help you in this, like htmlspecialchars and filter_input in PHP, and some frameworks like Django already escape what they can when printing variables, see https://docs.djangoproject.com/en/3.0/topics/security/#cross-site-scripting-xss-protection
©️ Cover Picture from https://www.geeksforgeeks.org/what-is-cross-site-scripting-xss/