Imagine that all of a sudden, you cannot log in to your favorite online shop. Moreover, someone makes some strange comments on your behalf and orders some purchases. Remember the one time you clicked on a link in the comment section of a website to check that jacket someone recommended? It seems you encountered a case of cross-site scripting (or XSS). Read below why it is dangerous and why it is so easy to fall victim to it.
What is cross-site scripting
Once activated, a cross-site scripting attack can leak a great deal of users' data to hackers, inject a Trojan, perform malicious redirects, impersonate users by stealing their credentials, etc.
Types of cross-site scripting
Reflected XSS takes place when a user clicks on a malicious link to a vulnerable website. Then the webpage reflects the script to the victim's browser, which executes it. A cybercriminal can then hijack the user's session cookies and steal their authorization data.
A website might not properly cleanse the incoming requests allowing cybercriminals to inject malicious scripts into a link. Its owners might also not be aware that someone uses their site for such purposes.
For example, Mary has an online shop, which Jane uses a lot. Jane logs in to the site by entering her username and password, which are stored in an authorization cookie. Tom is the bad guy. He finds out that Mary's website contains a vulnerability, crafts a malicious URL, and sends it to Jane in an email disguised as an attractive offer. Jane clicks on the link and executes the script. The script then infects Jane's browser and sends all the login details associated with the website's login cookie to Tom. Tom can log in to the online shop as Alice, steal her billing info, and change passwords.
In stored XSS, hackers don’t just inject malicious script into a single link — they plant it on a website's server. They hide the script in a specific section of the site, where it can lurk for an indefinite time (e.g., comments section). So whenever users access this section, the hackers can get all their credentials associated with that session. If a reflected attack reminds fishing with a rod, a stored XSS operation is more like a net with its ability to affect way more users.
For example, Alice discovers a vulnerability on John's website and injects a malicious HTML tag in its comment section. It just stays there. Now when visitors visit the comment section, the tag activates the hacker's script hosted on a different website. It sends her all the data from their authorization cookies. She then can log in to the site and impersonate every compromised user.
The self-XSS attack does not rely on a vulnerable website — instead, it tricks users into injecting a malicious script into their own browsers. Usually, cyber criminals employ social engineering tactics for this. For example, they can persuade a user to enter code into their browser by promising that it will allow them to access another account with extra benefits. However, that just allows the hacker to steal the victim's account.
Cross-site scripting prevention
XSS attacks are well hidden on the code level, so you might not notice one for a very long time. What is worse, the owners of vulnerable websites also frequently identify XSS way too late. However, as always, there are some measures to prevent it:
Always use the most up-to-date and reliable security software, which might automatically block you from entering malicious websites;
Always update your browser to make sure you use the latest version. Make sure your browser has anti-XSS security features;
Do not open any suspicious links even if they look legitimate at first sight. Always properly check the URL to see if there is nothing uncommon there;
Always contact the people behind a website if you notice something suspicious (e.g., you cannot log in with your usual credentials, you see some purchases you did not make, etc.).