Skip to main content
March 31, 2015

Exploit Profile: All About Cross-Site Scripting

Exploit Profile: All About Cross-Site ScriptingThink you have to make a foolish mistake for an exploit to do nasty things to your computer or website? Think again. One of today's most common attacks relies on victims accessing a subtly compromised page or clicking a specially crafted link, and nothing more. From there, attackers can view and steal sensitive information, modify files and content on the affected site, and hijack the user's browsing session or computer — in addition to other unpleasantries.

Cross-Site Scripting (XSS) is one of the meanest exploits in modern attackers' toolboxes. It's also one of the most prolific. Social media giants such as Facebook and Twitter (and, by proxy, their users) have fallen victim to versions of the attack, as have major Internet players such as Yahoo. Moreover, several big-name businesses currently exhibit or have exhibited susceptibility to XSS, showing just how tricky it can be to pin down.

XSS Explained

Though Cross-Site Scripting's original definition described one specific type of attack, several thematically similar exploits now fall under its banner. As a result, it's hard to categorize its different forms, but there are attributes all attacks share. At a high level, one OWASP article states XSS occurs when "malicious scripts are injected into otherwise benign and trusted websites." To that end, much of the variety in XSS attacks comes down to two factors: how the attackers inject the code and what they want to access or accomplish.

More often than not, the injection occurs when unsuspecting users click a link specifically crafted to attack the site they're visiting. Sometimes this is a direct link to the site in question, modified to get the intended results (more on that below); other times a user may need to visit a cleverly disguised site under the attacker's control. Other attacks rely on social engineering and trick users into running malicious code on a specific part of a website.

Take Facebook account hijacking, a particularly nasty bit of online malfeasance given the site's prominence and the increasing importance of online reputations. Attackers trick victims into pasting code to a certain area of the site to gain access to their accounts. Once inside, hackers can post spam, scam other users who ostensibly trust the victim and so on.

That said, victims don't always need to take such direct action to harm themselves or the site in question. With sites that rely on user-generated content such as forums and comment sections, attackers can post malicious code that infects others who view it. More frequently, they trick users into clicking a link containing the unsavory code, which is then automatically posted or executed. In this case, attackers can hijack a victim's browsing session and gain access to that victim's account, including the ability to view restricted info and other elevated privileges. This can result in information theft, site defacement and outages. In some cases attackers may even fully hijack a victim's web browser.

Protecting Against XSS

As Veracode's Cross-Site Scripting cheat sheet says, there are three main protection methods against XSS:

1. Sanitization. To avoid "persistent" XSS attacks (i.e., the ones undertaken on dynamically generated content such as forums), input sanitization is your best friend. By preventing malicious users from running code in input sections via smart, consistent filtering, you eliminate a widely used avenue of attack.

2. Encoding output. Make sure your users' query returns are relevant and, more importantly, not harmful. Of particular note here are special characters: Question marks, ampersands, angle brackets and other characters frequently used in coding should be returned to users in their encoded equivalents, where applicable.

3. Allowing users to turn off client-side scripts: If your web application relies on client-side scripts, consider giving users the option to terminate them altogether. It's a "development trade-off," as the data sheet says, but it can also result in a safer experience on the user's side and a more secure product on yours. You may also go the reverse route, leaving it off by default but allowing users to opt in under certain circumstances.

Keep XSS in Check

As with this update on SQL injection, it's important to note XSS takes more forms and requires more measures than one blog post can fully cover. No matter how secure you think you are, consider seeking expert help. With so many variations, keeping a tricky exploit like XSS in check is one of the smartest security moves you can make.

Photo Source: Flickr

Related Content

Evan Wade is a professional freelance writer, author, and editor from Indianapolis. His time as a sales consultant with AT&T, combined with his current work as a tech reporter, give him unique insight into the world of mobile/Web security and the steps needed to properly secure software products. Follow him on Twitter.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.