I first became aware of cross-site scripting (XSS) nearly a decade ago. At the time, despite being an all too prevalent bug in Web applications, the risk posed by the flaw was of limited value. It was the go-to vulnerability for any pen tester that was having trouble digging up a meaningful vulnerability to add to his audit report.
That has all changed now. Today, XSS represents a meaningful threat — a threat that is not only leveraged by attackers to harvest authentication credentials, but also is enabling a new generation of malware in the form of Web-based worms.
What Is XSS?
Depending upon whom you listen to, the statistics may be different, but virtually all agree that XSS remains the most prevalent Web application vulnerability that we face today.
In its latest security statistics report, White Hat Security found that 65 percent of the sites it tested had XSS vulnerabilities. Why is it that after nearly a decade in the spotlight, XSS remains so prevalent?
There are three reasons: First, XSS can exist anywhere user-supplied input is accepted and used by an application. In today’s Web, where user-supplied content is not only allowed, but also encouraged, that leaves plenty of opportunity to introduce a flaw into an application.
Second, we have failed to educate developers when it comes to security. To this day, most development textbooks actually teach insecure coding practices and largely ignore the concept of input validation.
Finally, product managers, development leads or those tasked with prioritizing engineering resources continue to treat correcting XSS vulnerabilities as a low priority, if they even recognize the threat at all.
What is XSS? In short, it is a vulnerability caused by improper input validation, which permits executable content to be embedded within a dynamically generated Web page. Now, that same definition could be used to describe a fairly broad array of vulnerabilities, so let’s break it down further.
Consider for example, a search page. An end-user searches for the word ‘apple’ and the Web application returns a dynamically generated page stating something like “your results for the search term: apple” followed by the results themselves. In this case, the word ‘apple’ in the previous statement represents user-supplied input that was used by the application and embedded into a dynamically generated page.
While others may argue that there are multiple flavors of XSS, I prefer to focus on two primary categories: reflected and persistent. As a general rule of thumb, think of reflected as a scenario where one attack equals one victim, while persistent permits one attack to target many victims. Let’s begin by focusing on reflected XSS.
The attack will generally complete when information is returned to the attacker. Most commonly, the attacker is after the victim’s cookie contents. With this information — assuming a password protected Web application — the attacker will then be able to impersonate the victim for as long as the session remains active.
What Has Changed?
While this still holds true, it’s simply not realistic if you want to enjoy the modern Web. The technologies that permit user-friendly Web design, such as Ajax, have now become so commonplace that many Web applications would simply become inaccessible should you chose to follow such advice.
A more important change involves the type to applications that we’re seeing on the Web today. At the turn of century, we referred to content on the Web as a ‘Web site.’ At that time, Web content was nothing more than an electronic brochure — a way for entities to advertise.
As Web technologies evolved, the term ‘Web application’ became commonplace. The Web was no longer static. Rather, content was dynamically generated based on user-supplied inputs. This also marked a surge in Web-based attacks, as the Web became interactive, opening up potential attack vectors.
Today, we are witnessing the growth of social networking sites such as Facebook, and we’re seeing a new entity emerging. We are witnessing the emergence of ‘Web platforms.’ These are no longer applications with fixed functionality, but rather platforms that empower users to become developers.
Third parties no longer simply supply content. Today, they also provide functionality. Users, on the other hand, no longer interact with such platforms simply as a utility to accomplish a task — purchase an airline ticket, check the weather, etc. Today, social networks have become trusted platforms where users choose to spend a significant portion of their day.
Social networks have evolved into not only the communication medium of choice, but also a gateway to access a multitude of external resources, and a storage medium for sensitive information such as contact lists.
It is the emergence of the Web platform, primarily in the form of social networks, that has paved the way for the future of malware. Traditionally, worms have traveled from desktop to desktop. Today, we are beginning to experience a new phenomenon: the Web-based worm, which instead travels from profile to profile, within a Web platform.
A very real limitation of Web-based worms is that they must live within the ecosystem in which they originated. However, when that ecosystem comprises 300 million accounts, that isn’t much of a limitation at all. Moreover, as sites continue to expose and share Web based APIs, the potential for cross-platform Web-based worms already exists.
Earlier this year, a 17-year-old, self-described “bored developer” provided us with another reminder of the potential of the Web-based worm. On April 11, numerous Twitter users began noticing that their account postings included items that they hadn’t submitted. The mysterious postings were promoting a previously obscure Web site known as “StalkDaily.com.” The culprit? A Web-based worm written by Michael Mooney. Michael had identified XSS vulnerabilities within Twitter — not the first such occurrence — that permitted him to write a Web-based worm.
1. A victim views a previously infected profile of another Twitter user
4. The cookie and username of the victim are forwarded to a server controlled by Michael Mooney
5. An image request is made to StalkDaily.com, another site controlled by Michael Mooney
6. Victim’s authToken (authentication token) is identified
Michael Mooney’s Web-based worm is a preview of what is to come. While Mooney’s worm didn’t do any permanent damage, future attackers may not be as kind. Web-based worms could be used to retrieve sensitive data such as contact information, spoof communication with other users, or even perform financial transactions on behalf of the victim.
Attack scenarios are limited only by the capabilities of the platform they leverage. Sadly, finding vulnerable platforms to create such an attack is all too easy to do, given the prevalence of XSS vulnerabilities.
The fact that most Web-based worms to date have been created by individuals without a profit motive illustrates that the attack technique has not yet matured. Bored and bright individuals are tinkering with the concept, while the true criminals wait on the sidelines ready to move in when traditional techniques fail to achieve desired goals.
This same pattern is repeated over and over again within cybersecurity. Worms were once the realm of those seeking to prove what was possible or to prove their technical prowess. Worms such as Sasser, Blaster and Slammer were big and loud, proudly boasting of their ability to infect millions of machines in the blink of an eye.
Today, malware is much more stealthy, trying to fly under the radar, as bold behavior will only undermine the true goal of financial gain. Web-based worms are sure to follow the same path, so it is wise to use our time to prepare for the threat and not ignore it.
Traditional malware controls including desktop antivirus aren’t focused on emerging threats such as Web-based worms. This next-generation worm exists online, not on the desktop. It travels in HTTP requests, not binary files that can be scanned by signature engines prior to execution.
Tackling Web-based worms requires defending against XSS attacks. As with any protection scheme, a defense-in-depth approach is recommended. At the host level, browser-based defenses are beginning to emerge. Plug-ins such as the excellent NoScript extension for Firefox address XSS, along with a variety of other threats.
Additionally, Microsoft is the first browser vendor to step forward to embed XSS protection directly into the browser with Internet Explorer 8. This is an important step forward. Enterprises that have not yet chosen to upgrade machines running IE, should seriously consider doing so for this very important security feature.
At the network level, enterprises should consider secure Web gateway (SWG) products and services. When doing so, whether choosing a software, appliance or SaaS-based offering, be sure to determine whether XSS protections are included, as such functionality is not universal.
Looking to the Future
Attackers adapt far more quickly than those tasked with defending networks from attack. They follow the money, and that means going where their victims are.
While Web-based worms represent a new attack vector made possible by the existence of XSS vulnerabilities in Web applications, XSS itself is already being leveraged today by attackers, primarily in targeted attacks. Enterprises should seek protection mechanisms that go beyond the basics of desktop AV and URL-filtering, as attackers moved on some time ago.
Michael Sutton is vice president, security research, at Zscaler.