SQL injection has been getting most of the attention lately, but the average SQL injection attack isn't nearly as sophisticated and difficult to pull off as a well-crafted cross-site scripting (XSS) attack: XSS affects all victims of a vulnerable Website, stealing their credentials, exploiting their Web browsers, and taking action on behalf of them without their knowledge.
XSS has been the reigning champion of Web application vulnerabilities in the sheer number of applications that house this vulnerability. Like SQL injection, XSS is a flaw caused by a lack of validation of user input. But instead of attacking the Web application or database server directly, the XSS attack hits the Web app's victims and executes malicious code in the victims' Web browsers.
The first two types of XSS attacks, DOM-based and reflected, are very similar but differ in how the injected code is treated by the browser. In both cases, an attacker injects code in a vulnerable Web app that is then executed on the victim's Web browser.
The difference between the two is that DOM-based attacks use injected code that calls to a vulnerable Web page on the victim's computer. DOM-based attacks are effective because in Internet Explorer, the local file system is considered the Local Zone and has different security privileges than if the vulnerable file was being viewed from a Web server. DOM-based attacks can be more powerful, possibly resulting in remote code execution with little to no user action needed.
It's important to point out that reflective XSS attacks, and most examples of DOM-based attacks, require some degree of social engineering to get a victim to click on a link in order to visit a vulnerable Web app. This is another reason that XSS is often dismissed as not being a critical vulnerability, but we all know how easily it is to social engineer people into clicking links.
Persistent, or stored, XSS attacks do not require social engineering to be effective because the attack is stored within the vulnerable Web app. The attack could be included as part of a forum, bulletin board, or mailing list archive that allows user-generated content to render when viewed on the page. The key distinction is that it can impact any visitor to an exploited Web app.
Incident response for XSS attacks can be difficult if you don't have all of the pieces to the puzzle. In the case of a reflected XSS attack, an investigation needs to include interviews with users to see if they received any strange e-mails or instant messages in which they clicked links.. Web application logs need to be reviewed to find the exact attack. Since clicking on a URL is part of a reflected attack, it will get logged by the Web server -- if the appropriate logging is enabled, that is.
Detecting persistent XSS attacks can be considerably more difficult? It requires examining all content of a Web app, including static files and dynamic content stored in the database.
The tricky thing about an XSS attack is that it can take on so many forms that there isn't a easy way to automatically look for all possible variations -- although it is possible to spider a Website looking for dynamic content.
So how do you prevent XSS vulnerabilities in Web applications? Follow the standard secure coding guidelines -- never trust input from users. Treat all user input as if it were malicious and perform input validation on all user input and HTML-encode it before displaying to the user's browser. These two steps won't prevent all attacks, but they're a good start. OWASP has an excellent XSS Prevention Cheat Sheet with detailed information on when and where encoding should be done.
XSS flaws and attacks are prevalent and powerful, and it's time to take XSS seriously before someone uses it to compromise your users and possibly, your server.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.