What should enterprises know about how a stored XSS exploit works?

VMware recently patched a vulnerability in its ESXi hypervisor that allowed for stored cross-site scripting. What exactly is a stored XSS attack, and how does it work?

Cross-site scripting, or XSS, is a web application attack that attempts to inject malicious code into a vulnerable application. The application isn't at risk during this attack; XSS' main purpose is to exploit the account or user attempting to use the application.

There are a few different types of XSS -- such as stored, reflective and others -- but in this article, we'll briefly go over the stored version of the exploit, which recently affected VMware's ESXi hypervisor.

With stored XSS, there is a method called persistent XSS, where an attacker aims to make an XSS exploit permanently part of an application, instead of it being a reflected XSS attack, where the user might have to click on a link to exploit the vulnerable app.

In this case, a permanent XSS exploit means the application can be modified to allow software -- such as a web browser -- to automatically load the exploit without user interaction. The stored XSS is not part of the app, and will load each time a user interacts with the application. This type of cross-site scripting is not as common as reflective XSS, but it's definitely higher risk. If an attacker is able to find a high-value application with a high hit rate, they can do a lot of damage.

An example of stored XSS would be an application, like a forum or blog, that allows input or data to be added to the site without proper sanitation checks. This would allow an attacker to insert a malicious script as part of the comments on the app. When a user scrolls through the site, their browser will notice the script and initiate it without the user actually clicking on anything.

This is normally done with some type of JavaScript hosted off site that the attacker has written and inserted. Once the script is written, the attackers can code the payload to do a number of things since, at this point, they're working as the signed in user. This method has been used many times to steal cookies or sessions, or to achieve access to an application itself.

Now, it's up to the attacker's script and creativity to determine what they can steal or modify. The possibilities are endless. For example, in VMware's case, the stored XSS flaw affected the ESXi hypervisor; if the exploit was used to gain the account credentials of the hypervisor administrator, those credentials could give attackers extensive movement within and control over the virtual machines managed by that hypervisor.

There are two groups that can help prevent stored XSS: developers and users. Developers are essentially responsible for the XSS exploit, and having proper coding practices, vulnerability scans and so on will go a long way to defeating the XSS exploit.

Unfortunately, as we've seen, this isn't always the case, and users are being directly affected by it. It's here that users can protect themselves by denying scripts being run in their browsers without their knowledge. Browser plug-ins like NoScript help protect against XSS exploits, but they need to be reviewed and taught to not deny legitimate scripts from running in the browser.

Ask the Expert:
Want to ask Matt Pascucci a question about security? Submit your question now via email. (All questions are anonymous.)