Tech Insight: XSS Exposed

A Special Analysis for Dark Reading

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.

Even though XSS is a pervasive problem, it's commonly misunderstood. Some dismiss it as a simple parlor trick because the typical example to show that an app is vulnerable to XSS is a JavaScript alert box that pops up saying "XSS." But when tools like BeEF (Browser Exploitation Framework) and Browser Rider are used with the same vulnerable Web page, it's obvious XSS is a serious attack.

XSS attacks can be extremely powerful and crafted to do a wide range of things and BeEF and Browser Rider are excellent examples of what mayhem can be wrought. Using BeEF, for example, an attacker can hijack the Web browser of a victim who browses a vulnerable Web page injected with a JavaScript "hook" that loads BeEF. The victim's browser now becomes a zombie controlled through the BeEF admin interface, and can be used for port scanning and exploitation of hosts within the victim's internal network.

There are three main types of XSS attacks: DOM-based, reflected, and persistent. It's important to note that while most examples of XSS use JavaScript, practically any scripting language and active content can be used to carry out the attack. The OWASP page on XSS states that "any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more."

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.

Reflective attacks are the most common type of XSS attack, and are usually the result of the Web app receiving input from a victim who clicked on a link sent by an attacker. The link usually has JavaScript, often encoded to obfuscate the attack that is taken by Web app and immediately "reflected" back at the victim -- executing within their Web browser within the security context of the vulnerable Web app.

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.