Cross-site scripting

IN EARLY 2000, CERT issued an advisory regarding a serious issue in many Web applications: CSS (cross-site scripting). (You can read the advisory at http://www.cert.org/advisories/CA-2000-02.html .) CSS is often overlooked as a threat to users and organizations.

CSS attacks occur when a user enters malicious data in a Web site. For example, a user can post a message to a newsgroup that contains malicious code. When another person views this message, the browser will interpret the code and execute it, potentially giving the attacker complete control of the system. Malicious scripts can also be executed automatically based on certain events, such as when a picture loads.

These attacks are dangerous and can easily lead to disclosure, modification, or deletion of data. And SSL (Secure Sockets Layer), the current standard in Internet data protection, does nothing to protect against CSS attacks -- all SSL does is encrypt the malicious script on the way to its destination.

The root of the problem lies in a lack of input validation. For CSS to be successful, script tags or some other kind of programming must be accepted as input. At a newsgroup discussing beagles, script tags and programming languages are probably not valid input data -- but they might be valid at a discussion group on VB Script. Application designers need to perform proper input validation checks before allowing a post to go through, such as filtering out script tags or carefully analyzing input data for appropriateness.

I recently came across an excellent Web site that discusses CSS and shows just how widespread the problem is: http://spoor12.edup.tudelft.nl/SkyLined/index.php , a site developed by Berend-Jan Weve, also known as h4x0r.

More and more, instances of CSS issues are being discovered and publicly disclosed. Some of the more recent reports include issues at eBay, Cybercash, and VeriSign. At http://spoor12.edup.tudelft.nl/SkyLined/docs/cross_site_scripting.archive.html , there is a list of sites with CSS flaws, meaning that at least one page has a CSS vulnerability -- a quick glance shows the list is a veritable who's who of the Internet.

The site also discusses how to bypass filters (i.e., sites that do filter script) through embedding and encoding scripts in various tags, URLs, or events. By identifying these runarounds, the page is trying to show that programmers need to address CSS in more detail (if they do so at all). This page is at http://spoor12.edup.tudelft.nl/SkyLined/docs/scriptspoofing_tutorial.html .

Obviously, many organizations are not taking CSS flaws seriously. Those that do need to stay abreast of the new ways attackers embed scripts. Simple filtering of script or other common tags is no longer effective; more detailed filters and built-in application security are needed.

An excellent tool to test Web sites for CSS issues is the newly released Linux-based WhiteHat Arsenal 1.05, available at http://community.whitehatsec.com . Commercial tools are also available, such as AppScan from Sanctum, WebInspect by SPI Dynamics, and ScanDo by KaVaDo.