It’s easy to become convinced of the danger posed by the latest and most notable online threats, but bleeding edge cyberattacks aren’t necessarily as widespread or as persistently dangerous as older ones. Take cross-site scripting (XSS) for example: Microsoft first identified and categorized XSS attacks in 2000, but records of XSS attacks go back to the earliest days of the internet. Bug bounty hosting website HackerOne reported in July 2017 that XSS continue to be the most commonly found vulnerability among users of its platform.
With the threat of cross-site scripting unlikely to diminish, it’s essential that internet users and web developers know what XSS is and how to prevent these cyberattacks.
SEE: IT leader’s guide to cyberattack recovery (Tech Pro Research)
What is cross-site scripting?
Cross-site scripting is what happens when an attacker takes advantage of a vulnerability in a webpage to inject their own code. That code can steal user information such as credentials, session cookies, and other sensitive data, and can even live persistently on a site to attack multiple users.
XSS attacks fall into two categories: Reflected and stored attacks.
Reflected attacks are quick, one-off attacks that rely on server-side scripts not properly sanitizing requests to eliminate scripts or other embedded objects.
An attacker using a reflected XSS attack has to get a user to click on a link, either through email, a malicious website, or elsewhere. The link contains a malicious script that a vulnerable website won’t strip away through sanitization, thus bouncing the script off the site and onto the user’s computer.
Stored attacks, while less common, are far more dangerous and destructive than reflected attacks. Unlike reflected attacks, which have minimal interaction with a website, stored attacks exploit a site to get it to save the malicious script an attacker wants to run on targeted computers.
A stored attack requires a website to store user information in a public place, such as a social media platform, online forum, third-party retail site, or similar site. More specifically, attackers require the website to allow unsanitized HTML to be embedded in the site that visitors would be unknowingly subjected to simply by viewing the page. As with a reflected attack, the script embedded in the infected content wouldn’t be visible, so no suspicion is raised.
Unlike reflected attacks, which require a user to click on a link, stored attacks don’t require any interaction from the user. Examples of stored attacks could include embedding a XSS in a username, a blog post, a product description, a forum post, or anywhere else unsanitized user-generated HTML content is allowed.
How big of a threat is cross-site scripting?
A recent study from Positive Technologies found that close to three quarters of websites tested are vulnerable to XSS attacks.If Positive Technologies is correct, that makes it far and away the most commonly exploitable flaw on the internet.
XSS attacks are capable of stealing sensitive data from users. One of the most sensitive XSS targets are session cookies, which verify a user’s identity on a website to allow the person to stay logged in while visiting multiple pages on a domain.
If an XSS attacker manages to steal a session cookie, they can duplicate the user’s active session, giving them access to anything the user is able to do on a website—make social media posts, edit personal/account information, change passwords, steal credit card information, make bank transfers, buy products from an ecommerce site, and more.
What are examples of major cross-site scripting attacks?
It isn’t hard to find evidence of XSS attacks on major sites going back over a decade. News articles abound with stories of successful XSS attacks, some of which even went unfixed years after the initial incident.
- A proof-of-concept XSS was posted on Facebook in 2008. Facebook patched the vulnerability shortly after its reveal, though it isn’t known if there were victims of malicious attacks prior to its public discovery.
- Twitter’s 2010 redesign contained an XSS vulnerability that Sarah Brown, the wife of former British Prime Minister Gordon Brown, fell prey to and unknowingly shared with her +1,000,000 followers. The exploit didn’t even require a click—simply a mouseover—to redirect users to a pornographic website.
- eBay users have been dealing with potential XSS scripts embedded in item listings for years, and by early 2017 the issue still hadn’t been fixed. In this case, malicious sellers added scripts to legitimate product listings to redirect users to a spoofed login page that harvested credentials before redirecting users back to a legitimate eBay page.
- Nearly 400,000 British Airways bookings were compromised by XSS that targeted the airline’s payment system on its website and in its mobile app. Potentially all of those transactions had their credit and debit card details stolen.
- The Samy Worm that affected MySpace in 2005 added a line about the worm’s developer to everyone’s profile saying he was the victim’s hero. Regardless of its benign nature, the Samy Worm used XSS to infect over one million MySpace users in under 20 hours, making it the fastest spreading worm in internet history.
- Yahoo faced a lot of security woes in the declining days of its email supremacy, one of which was an XSS phishing attack in 2013 that resulted in victims having their accounts stolen.
These examples are, unfortunately, only some of the major, well-publicized cross-site scripting attacks. It’s entirely possible—and quite likely—that other XSS attacks will happen that result in the theft of personal information.
How can developers protect their web apps from cross-site scripting attacks?
Web developers whose projects fall prey to XSS attacks have only themselves to blame for leaving a vulnerability open to exploitation.
In some cases preventing XSS can be as simple as adding a couple of HTML tags to a website. While it isn’t always that simple, a practice called encoding is a good place to start.
There are cases when encoding isn’t ideal, such as when your web application needs to accept rich data input instead of only text.
Encoding isn’t always sufficient to stop XSS attacks, either. For example, if an attacker provides user input that links to an external instead of putting it directly into an input field, they can often deliver malicious code without it being subject to encoding filters. This doesn’t mean you should ignore encoding as a preventative measure—it should be supplemented with additional safeguards like validation.
Validation is the second major method of XSS prevention, and it involves stripping out malicious code without eliminating all the code that may be present in user input. Validation is generally done in one of two ways: Classification or sanitization.
Classification is a method of specifying what kinds of HTML tags are allowed and which aren’t; this can be done by blacklisting or whitelisting certain commands. Whitelisting is generally considered to be the superior method, as it minimizes what is allowed and eliminates the potential for things to be left out of a blacklist.
Classification acts on user input as it comes in, classifying it as either acceptable or inappropriate. If input fails to meet the criteria of a whitelist or blacklist, it is simply not allowed.
Sanitization uses a validation engine to determine if specific parts of a user’s input are malicious, and when it is the site chooses either to reject the input or sanitize it of offending elements.
In cases where users need to rely on complex HTML, input sanitization can be the best option because it will allow most of a user’s code to run while blocking anything the engine deems as inappropriate. Excess XSS, a site detailing XSS attacks and how to prevent them, warns that sanitization engines shouldn’t rely on blacklisting to identify invalid inputs, which can render sanitization ineffective. Instead, Excess XSS recommends using sanitization libraries and frameworks for a thorough, complete whitelisting approach to sanitization.
A third approach gaining traction is content security policy (CSP), which prevents any resources (scripts, stylesheets, files, etc.) from executing if they aren’t from a trusted domain. Since injected scripts likely won’t be from trusted domains, they won’t be allowed to run, and the attack should be prevented.
The World Wide Web Consortium (W3C) says that CSP shouldn’t be considered a replacement for validation or encoding. Rather, “CSP is best used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding.”
Other approaches to XSS prevention include blocking scripts altogether, increasing cookie security to tie them to IP addresses, and forcing cookies to use the SameSite=Strict parameter in Chrome, Opera, and Firefox versions newer than November 2017.
If you aren’t sure which approach to implement, you should do research to find which one is best for your site. When in doubt, it’s never a bad idea to rely on multiple methods.
How can internet users protect themselves from cross-site scripting attacks?
XSS is primarily a problem for developers whose sites are exploited to pass cross-site scripts off to users. There isn’t a lot that end users can do to protect themselves against XSS attacks since those vulnerabilities rely on weak website code to operate.
That doesn’t mean you’re out of luck when it comes to XSS attack prevention, though—it just means your options are limited. If you want to add more protection between you and a potentially untrustworthy website, heed these tips.
- Never click on an email link asking you to log in to a website—it could be a phishing request, or it could be loaded with cross-site scripts that (even if it takes you to a legitimate website) are prepared to rob you blind. If you receive an email asking you to click on a login link, it’s always best to open a browser and sign in to your account without following the link.
- Use a script-blocking browser add-on such as ScriptSafe (Chrome) or NoScript (Firefox). These add-ons completely block scripts from running unless you manually allow them; this should prevent XSS attacks from being able to execute.
- Avoid clicking links on social media if a post or private message seems unusual. Hijacked accounts are often used to spread malware and launch XSS attacks, and avoiding them can require being aware in the same way you would avoid a phishing email.