Video Screencast Help
Security Response

Cross-site Scripting Vulnerabilities

Created: 04 Jul 2006 07:00:00 GMT • Updated: 23 Jan 2014 18:59:02 GMT
David McKinney's picture
0 0 Votes
Login to vote

Cross-site scripting (XSS) is hardly thescourge of the Internet, but at the same time, should it really betrivialized when it affects a widely used service or application?Cross-site scripting (and the broader category of content injectionvulnerabilities) is incredibly prevalent across a wide range ofsoftware, from guestbook programs churned out by weekend warriors, tohousehold names with revenue statements that eclipse the gross nationalproducts of some small countries.

These vulnerabilitiesare so common that most people just wish they would go away. So, if wewant something to go away and we're not willing to expend the time andenergy to develop a real solution, then what alternative do we have? Dowe just pretend that they don't exist? The suggestion is often madethat they aren’t real—nothing to see here—move along.

Some people contend that XSS isn’t a real vulnerability because itcan’t affect security with hosts or end users on its own, or when usedin a product or script it doesn’t result in direct loss of data. Someaccept it as a surcharge that accompanies JavaScript—support foramazing, dynamic, client-side content—and in exchange all you have todo is surrender the document.cookie property to anyone who wants toread it. When it comes to the majority of popular Web-based services,the service is a far greater asset than the host itself, because it canaffect thousands or even millions of users. If an attacker can injectarbitrary, false, or malicious content into such a service, then thatis a direct impact to the integrity of the service! It would be easyenough to exploit a content injection vulnerability in order to seed asite with malicious code, such as a client-side browser exploit.Likewise, it's possible to spoof content to launch phishing attacks ordeface the site. Maybe these attacks fall under the broad category of"social engineering", but I find it hard to blame the victim when asite they have visited every day for years suddenly begins serving themup a zero-day client-side exploit in their favorite Web browser, justbecause an attacker has used cross-site scripting as a means ofembedding hostile content in a trusted Web site. What about when thevictim discovers that the email account they've used for years is nolonger their own; or, when the maintainer of a Web-based communitysuddenly finds their site defaced?

What I’m trying to say here is that while there are certain dangersassociated with visiting random sites on the Internet, the whole pointof cross-site scripting is to embed hostile content into a Web sitethat is trusted or familiar to the user. If the victim doesn't have anaccount on the site, there's no session to hijack. If they haven'tentrusted their private information to the site in the first place,then this information cannot be stolen from the site. The point is,these vulnerabilities tend to catch users off-guard. A normallycautious user would be less suspicious of hostile content originatingfrom a site they trust, but would otherwise be wary when randomlybrowsing the Internet. This is especially the case with HTML and scriptinjection attacks, which differ from traditional cross-site scripting,in that the attacker doesn’t necessarily need to trick the victim intovisiting a malicious URL.

All vulnerabilities must be taken in the context of their relativeimpact, but the impact of any real attack also depends on thecreativity and motivation of the attacker. If this Web 2.0 thingflies, the role of the Web will change drastically. Much more emphasisand focus will need to be put on the security of Web applications andWeb-based services. If this entire class of vulnerability is thrownaround without consequence, then what are the consequences of absolvingan entire generation of software developers for failing to performbasic validation of user-supplied input?

Ultimately, it would be foolish for us to brush vulnerabilitiesunder the mat when they affect the most well known services on theInternet. If recent incidents involving sites like PayPal and Yahoo!Mail are any indicator, then Web application security has a long way tocome. Or, if you prefer, you can subscribe to the solution of investingin a super rocket-powered broom to brush these issues into the dustbinof obscurity.