In the world of websites, hackers have a variety of tools to intrude on people’s domains. These hacks, which take advantage of vulnerabilities in a site’s code, are categorized by projects like the OWASP Top Ten.
According to the OWASP assessment, the top three most common attacks are:
As new vulnerabilities are discovered, we still can see that a large portion of these vulnerabilities are XSS-related vectors.
Even with increasing public awareness about web application security, web developers often overlook XSS vulnerabilities. By themselves, these attacks cannot take over the vulnerable web application, nor can they infect the visitor’s computer or damage their system. Developers may say, “Since XSS attacks are only seen by end-users, they can’t hurt the site… so, they are only a problem for ‘end users’, right?” This is an easy attitude to take, but XSS vulnerabilities can easily lead to more harmful attacks.
When a site has an XSS vulnerability, malicious JavaScript code can be sent from an attacker to an end user via a website.
Bad actors can:
JavaScript only runs on the visitor’s browser, which greatly limits what it can do. However, the well-known Neutrino exploit (the recent attack that infected client computers through Flash exploits) was initiated by malicious JavaScript. Even by only using pure XSS exploits, phishing attacks and stolen session cookies are used by attackers to steal accounts, with hopes to hijack an administrator’s session to take over the site entirely.
At a minimum, a XSS vulnerability can endanger client accounts and information, but also has the potential to be exploited to take over a website. Paired with other exploits, injected XSS can particularly endanger site visitors who are running old or unpatched software. If this is a known problem, why are XSS vulnerabilities still so common?
Part of the reason XSS vulnerabilities are still popular may be because cyber criminals are mainly known for stealing information or taking over websites. These attacks can be either ‘persistent’, saving malicious JavaScript on the server, or ‘reflected’, sent directly to an end user via a link or page. They can also be as simple as swiping a session cookie by tricking someone to click on a maliciously-shaped link to the vulnerable website. In the example below, through a ‘reflected attack’, a vulnerable site spits out the visitor’s site cookie (in this case, it is then graciously shown to the visitor).
The idea of a hack that neither infects the targeted site nor steals information seems strange, and even more strange is that XSS can still be utilized on sites that do not use session cookies or have accounts to hijack. But as strange as it sounds, having your website be a participant in a XSS attack against an unrelated site is an issue, especially for regular users of your website. Developers must always keep in mind what your end users can control!
In part 2, we will talk more about reflected XSS attacks and share some advice on fixing these vulnerabilities. It isn’t always quite as simple as it looks. Stay tuned.
SiteLock has products that can help keep bad actors from exploiting vulnerabilities on your website. Visit sitelock.com to learn more about our web application firewall, website scanning services, and TrueCode Static Application Security Testing.