This Week in Exploits: What Are XSS Vulnerabilities? Part 2

In last week’s “episode” of ‘This Week in Exploits’, we talked about Cross-Site Scripting (XSS) and specifically reflective XSS vulnerabilities, the most common type of XSS flaw. We now know roughly what a XSS attack is, and some of what a reflected XSS attack does, but why do XSS attacks exist? How can they be used?

In brief review, XSS attacks operate by either saving malicious JavaScript onto a site (persistent XSS) or having a web application return JavaScript in response to user input (reflective XSS). Attackers will use XSS to ‘respond’ in a reflected attack by crafting a link or a form that a target will use. Many end users interact with spam emails, especially well crafted ones that look legitimate, and this is precisely how attackers use reflected XSS vulnerabilities.

The example below shows an uploaded phishing file being used to steal Outlook emails. A link in a spam email can easily show a fake sign-in page using reflected XSS. Alternatively, a ‘persistent’ XSS attack could inject a fake login page into the site code, saving a hidden phishing page on the site.

Figure 1: Outlook Phishing Page

Phishing pages send stolen logins from one of these fake login pages to a hacker. Hackers will then test the password/login combination on different sites, to see if that combination has been reused elsewhere. The script below, which swipes logins to a video site and sends those credentials to multiple bad actors, could be hosted on almost any website.

Figure 2: Phishing Script

This phishing example doesn’t require any special target on the vulnerable site, the attacker is merely using the site to ‘bounce’ the fake login to an end user. Hackers often take over sites to use their resources, and using reflected XSS is just another example of a hacker using someone else’s site to conduct their attack.

While persistent XSS attacks can be found and cleaned, reflected XSS don’t create any files, infect any servers, or leave any major evidence of a hack. To see examples of reflected XSS in the wild, a developer would have to be visiting suspicious links, or filling out suspect forms. The best chance of finding reflected XSS attacks using their own site would be finding and analyzing evidence in their site’s logs.

Reflected XSS is almost always only seen by an end user. A suspicious email with a reflected XSS attack would have a link that leads to the vulnerable site; a strange link, but one to a ‘safe’ source. A confused or unknowing end user could easily fall for a phishing attack, or be hit by a second redirect to a malicious site. And there are many, many spam email campaigns, infected links, phone robo calls, all directing people to malicious sites or phishing links. XSS attacks are one of the many tools in this spam arsenal, and XSS is one of the most common security flaws across the internet’s multitude of websites.

Fixing XSS

XSS vulnerabilities are common, but they are much easier to fix than complex vulnerabilities like CSRF. Without direct signs of malicious activity reflected XSS is often missed, but if they are known and searched for, they can be patched. As we now know, a threat to your end users is still present if that vulnerability exists, and no one wants their own website to be partially responsible for infected computers or stolen logins.

For developers fixing XSS vulnerabilities, there are many filtering methods available in web application software for converting input to safe text. Any user input that can be displayed to a site visitor should to be audited and filtered. Sometimes vulnerabilities are created when these are methods aren’t applied strictly enough, and patching XSS sometimes requires knowing the ‘best fit’ for the situation. The OWASP Top Ten provides an example sheet of how hackers can slip through mismatched XSS filters, and this sheet is useful for web security audits and web developers alike.

In many cases, vulnerabilities are simply missed during development. In large web applications, it is hard to find and secure every entry-point. SiteLock’s ‘360 Website Malware & Vulnerability Scanning’ includes multiple modules for finding flaws that bad actors can take advantage of. For website owners who don’t have web developers to rely on, SiteLock also provides vulnerability remediation to fix those flaws (and the full scanner suite) through SiteLock INFINITY. Prevention is also a worthy goal, and SiteLock’s TrueShield WAF will block many varieties of attack used on a website.