Picture a potentially reputation-damaging attack in which user accounts are compromised, page content is unlawfully modified, and users are tricked into giving up their private data.
Welcome, unfortunately, to the world of cross site scripting (XSS) attacks: an increasingly common attack vector in which malicious code is injected into vulnerable web applications. Unlike web attack vectors such as SQL injections, XSS attacks don’t target a web application — but rather the users of that web application. They’re bad news and they’re getting worse. Or, at least, more prevalent.
In this article, we’ll introduce XSS attacks, discuss one of the recent XSS vulnerabilities that could easily have led to such an attack, and discuss methods to protect yourself such as a Web Application Firewall.
What is an XSS attack?
Let’s start with a bit of background to better understand XSS attacks: In computing, the Same Origin Policy (SOP) is a key aspect of web application security for every internet browser. It means that a web browser allows scripts on one web page to access data from a second, although only on the condition that both come from the same origin. For example, websiteexample1.com/index.html would be able to access data from websiteexample1.com/thispage. However, it could not do the same with content from websiteexample2.com. This is intended to stop malicious script from one page gaining access to data on another for security reasons.
A Cross-Site Scripting (XSS) vulnerability or attack gets around this defense. When cyber attackers carry out such an attack, capitalizing on vulnerabilities in a website’s software, they are able to maliciously insert their own code into a victim’s website. Whenever the site is loaded, the malicious code will be executed. This allows the hacker to read about and steal sensitive information from the victim. For instance, that could mean hijacking a user’s session by accessing session cookies that allow an attacker to pose as the victim and gain access to their web session. By logging into the web application, they may then compromise an entire website. Alternatively, they could perform unauthorized activities such as posting material, injecting a keylogger to capture keystrokes made by the legitimate user, or more.
There are two broad categories of XSS attacks: stored and reflected attacks. A stored or persistent XSS, the nastier of the two, takes place when hackers inject a malicious script directly into a vulnerable web application. Reflected XSS, meanwhile, refers to an attack in which the injected script is reflected off a web server that includes part or all of the input sent to a server as part of a request. Reflected attacks can begin with a user being fooled into clicking on a certain link, submitting a form, or browsing to a malicious website.
The KingComposer vulnerability
XSS vulnerabilities are extremely prevalent, and are likely the most frequently discovered web security vulnerability. One recently discovered XSS vulnerability was found in KingComposer, a WordPress plugin for Drag and Drop page-building that had been installed on over 100,000 sites worldwide. In order to carry out this Drag and Drop page-building, the plugin registers a series of AJAX actions, a technique for creating dynamic and fast web pages that allows parts of a web page to be updated without reloading the whole page. One of these AJAX actions was no longer an active part of the KingComposer plugin. But it could still be accessed and used to deliver a malicious payload to a target’s browser.
The XSS vulnerability was rapidly patched after being discovered. However, this still requires users to update to the latest version of WordPress. Users who have not updated to version 2.9.5 or above are still at risk of the exploit.
For the most part, well-known CMSs (content management systems) like WordPress are very secure today. But the KingComposer XSS vulnerability shows how such security flaws are still a big part of the modern computing landscape — and why, with thousands (or more) potential victims, they represent an attack vector that hackers will rely on more and more in order to achieve their goals. Outdated or leaky plugins — or even, as the KingComposer vulnerability shows, AJAX actions that are no longer used but still exist — represent a big threat to be wary of.
Web application vulnerability management is hard work due to the number of vulnerabilities and the increased use of third-party code.
Protecting yourself against attacks
To protect against XSS attacks, you should make sure you keep up to date with all the code that’s running on your organization’s site. That means ensuring plugins and the like are all updated, regular security assessments are made, and more.
Of course, not everyone has the time or expertise for this. The most common — and scalable approach — an organization can take to protect themselves against XSS attacks is a web application firewall (WAF). These firewalls utilize signature-based filtering in order to spot and block malicious requests and counter XSS attacks. A well-managed WAF service will also be backed up by a team of knowledgeable security experts who can make sure that the security rule set is constantly updated with the latest attack vectors that have been discovered.
XSS attacks are on the rise. However, by taking the right precautions you can ensure that you are not among those targeted. It’s an investment well worth making.