Nmedia - Fotolia
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.
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.)
Learn why many organizations are struggling to catch XSS vulnerabilities
Discover the differences between XSS and XSS inclusion
Find out how to prevent same-origin policy XSS vulnerabilities
Dig Deeper on Application attacks (buffer overflows, cross-site scripting)
Related Q&A from Matthew Pascucci
Understanding the differences between sandboxes vs. containers for security can help companies determine which best suits their particular use cases. Continue Reading
Troubleshooting VPN session timeout and lockout issues should focus first on isolating where the root of the problem lies -- be it the internet ... Continue Reading
What sets web roles and worker roles apart in Microsoft's Azure Cloud Services? Here's a look at how they are different. Continue Reading