What should enterprises know about how a stored XSS works

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. Read the rest of my article at the link below:


This is a Security Bloggers Network syndicated blog post authored by Matthew Pascucci. Read the original post at: Frontline Sentinel