XSS: The Con-Artist
“XSS” is an acronym you hear often in the field of information security. It’s a relatively common attack for both the client and the server. Acronyms can make you think that it’s a bit more hi-tech and complicated than it really is. But at the root of it, XSS is basically a con-artist, waiting for his next ploy.
What is XSS?
There could be a variety of consequences: It could alter the display, modify the browser, or even steal your session cookie and sign in as an administrator, which could give complete control over to a hacker.
But I use the word “could” because there’s a lot of variety and uncertainty when it comes to the XSS vulnerability: what the consequences can be when they can happen, and to what extent they reach. So let’s make it a bit easier to process.
Think of the XSS vulnerability as a con artist’s latest trick. You never go out looking for a con-artist, but in some way or another, they get you right where they want you.
Non-Persistent XSS: the Pickpocket Scam
Pickpocketing is the oldest trick in the book, proven to work time and time again. It’s become a common and simple way for attackers to get their target. The pickpocket may approach you as the “nice stranger” who’s asking for directions on the street. But their hand reaches to take your wallet from your pocket while you’re explaining directions. Though the pickpocket targeted you, when the ordeal is done and your money is gone, it’s as if it never happened.
It’s the same with Non-Persistent XSS, the most common type of XSS. An attacker will inject a script that’s targeted and contains the malicious script. You click it and fall for the trap. But just like with a pickpocket, when the code is injected and you have been fooled, none of what happened goes to the server. The website will simply execute the script and reflect it back to your browser, and the cookies will go to the attacker. The immediacy and the lack of detectability are the highlights of these non-persistent XSS attacks.
Persistent XSS: The ATM Skimmer
On the other side, Persistent XSS is much less common. While it has the potential of causing more significant damage, it can also be found out and remedied quicker. Think of an ATM skimmer. A skimmer is an electronic device that is placed within or outside an ATM. It takes the information that a customer may put into the ATM. The difference? While the skimmer may look the same as the ATM that the customer uses on a daily basis, it is copying all information and relaying it to the con-artist. It’s non-targeted, so everyone who uses the ATM will be affected without discrimination.
Like the ATM skimmer, the website may look the same as it usually does after the malicious script has been injected. It is saved by the server and then displayed on normal pages. All users who are browsing the website will be subject to the XSS. It will be affected over and over again. In fact, this is why this type of XSS vulnerability is much more dangerous. Damage can be done to a wider breadth of users without anyone knowing that there is anything amiss.
Fortunately, because this type of XSS takes place on a server – if someone is able to spot the unwelcome script, it can be remedied. In the case of the skimmer, perhaps the ATM maintenance crew notices that there is a bar code missing, or a warranty seal that’s in the wrong place. They can take quick and urgent steps to make sure that the skimmer is removed.
XSS Exploits in Real Life
XSS-affected websites can suffer from a variety of issues. Unfortunately, websites with a large number of active users are often affected through both persistent and non-persistent XSS. Recently, a Persistent XSS vulnerability was found on PayPal’s website. This would have allowed hackers to inject code resulting in a malicious payload, potentially opening up attacks for its 150 million customers. Thankfully, the company was notified of the vulnerability before any negative impact. But of course, there are companies that aren’t so lucky.
Hackers will always find popular websites, big or small, to execute their attacks, so what can you do to protect your website?
- Source Code Analysis: Source code analysis tools are used to find security flaws by going through the source code line by line. Ideally, this tool will be used before the website goes live. This way, problems can be remediated before any issues arise.
- Vulnerability Scanners: There are security scanners that will identify vulnerabilities like XSS. Although they’re not perfect (because they’re not optimized for your website or application specifically), they can allow you to find the most obvious vulnerabilities to clean up.
- Web Application Firewall: Web Application Firewalls or WAFs follow rule-sets to detect or block anything suspicious. WAFs will normally prevent attacks such as XSS and SQLi as part of their rule-set. Make sure that your WAF is one that has low false-positive rates. That’s it! You’re well on your way to having a safer, cleaner website.
Which method is the most effective? As I always say, there’s no perfect way to escape any form of web attack. But the best thing you can do is follow the points above like a process. Source code analysis tools will scan for flaws before anything goes live. Vulnerability scanners will then look for further issues as the website is up. A WAF will block the attempts that manage to slip through the cracks. Unfortunately, nothing is foolproof. But risk can always be reduced and controlled.