Cross-Site Scripting Security Exposure Executive Summary

Originally Posted: February 2, 2000

On This Page

Abstract
The Problem
How Is It Done?
Consequences
How Do I Protect My Site?
Conclusion
Disclaimer

Abstract

Microsoft Research has identified a new class of security attack based upon the common development practices for websites and the basic assumptions that web browsers make when communicating with web servers. This security attack is called cross-site scripting. This is not a vendor-specific issue; it affects every web server and browser currently on the market.

The attack involves web servers that dynamically generate HTML pages. If these servers embed browser input in the dynamic pages that they send back to the browser, these servers can be manipulated to include content in the dynamic pages that will allow malicious script to be executed. Web browsers may perpetuate this problem through their basic assumptions of "trusted" sites and their use of cookies to maintain persistent state with the websites they frequent. This attack does not modify website content; rather, it inserts new, malicious script that can execute at the browser in the information context associated with a trusted server.

This security issue is conceptually easy to address and prevent. The challenge faced by organizations will be two-fold:

• Analysis. Web programmers will need to analyze every web page that makes up a website to look for potential security breaches.

• Fix & Test. Due to the great variation in customization of web code, there are no automated tools currently available to assist in this process. The work must be done manually and will therefore be more time consuming.

The Problem

Web pages consist of more than just text from a web server that is displayed by a browser. They can contain built-in program elements known as scripts. These scripts are executed on the server or on the client. Website designers can use scripts to perform online transactions, dynamic searches, advanced navigation, and much more.

Within HTML, certain characters are considered "special" so that servers and browsers may distinguish between normal text for display and elements that provide functionality. The cross-site scripting security breach is exploited by inserting special characters into client-server communications that introduce rogue scripts.

The vulnerability arises when web servers generate dynamic web pages, such as when a search engine performs a search and then dynamically generates the search results page. If the generated content can be manipulated to contain the special characters mentioned earlier, the receiving browser will see them as valid and coming from a trusted source. The browser will then execute the inserted script.

The essence of the attack is that the browser will execute the malicious script in the security context of the site from which it believes the script came, not the attacker's site. By doing this, the attacker has access to everything within the presumed secure environment of the victim server and client. This is why the attack is called "cross-site."

How Is It Done?

Cross-site script attacks are focused on a specific victim website and the people who visit it. While it is possible to use this attack against a specific individual, it is unlikely to be worth the attacker's development effort to victimize a single web user. The most likely candidates for cross-site script attacks are e-commerce sites.

The attacker must first analyze the victim site to develop the malicious script and the method of insertion. If the attacker is interested in receiving information (such as credit card numbers) back from the victim browser, he will have to develop the receiving components prior to the attack as well.

The attacker will then entice web users to interact with him through email or some other interesting content on a seemingly innocent web page. When the victim browser interacts with the attacker site, the link redirects either all or part of the browser request to the victim web site and in the process introduces the malicious script. This can either happen in view of the browser or hidden from the browser, depending on the scenario set up by the attacker. The door is now open. The browser then runs script from an untrusted source as if it comes from a trusted one. The malicious script may then persist as part of a cookie.

In the most common scenario, the attacker is counting on the fact that a percentage of the infected victim browsers will visit the victim website at some point. When the victim browser does this, the attacker has the ability to do whatever he pleases even though both the server and the client believe that they are in a secure one-to-one environment.

Consequences

A cross-site script attack can have potentially serious consequences. It is important to remember that this type of attack is not aimed at altering existing web sites. It is aimed at inserting illegitimate script into a browser environment that is perceived to be secure.

The effects of these attacks could range from mischievous to criminal activity. A search engine could return random and/or ridiculous search results. Insulting language could be inserted into common web elements such as a page that recognizes users who have been to the site before and greets them using their first name. This message could be altered to greet a person with a profane message. On the more serious end of the scale, credit card numbers could be funneled to unauthorized locations, sensitive data could be retrieved from behind firewalls, or critical data could be destroyed. The extent of the attack is limited by the ability of the attacker and his willingness to behave in a deviant fashion.

How Do I Protect My Site?

There are two steps that all organizations will need to take to protect against this threat:

• Short term: inventory, analyze, fix, and test the existing site. Filters for special characters will have to be applied to all pages where user input is processed.

• Long term: adjust standard development practices to include the implementation of filtering.

The method for repelling the cross-site script attack is to implement filters for special characters from input and/or output of the website. The burden of addressing this issue primarily resides with the server side of the web. In general, websites will have to filter either input or output, but not necessarily both. There are pros and cons to each. These factors are discussed in the technical documentation of this issue.

The complexity of the issue, as well as the timeline and finances necessary to fix it, will differ for every organization. A few of the variables will be:

• the size of the site

• the number of development teams used to create the site

• the existing development practices of the site (such as the use of templates and/or cascading style sheets)

• the availability and capability of internal development resources

• the availability and capability of external development resources

• availability of automated tools to assist in this effort

Conclusion

The cross-site scripting issue presents a significant challenge for the web community. This issue is not localized to one type of web server or browser; it affects all web technologies that make use of scripting. Furthermore, this document presents a limited set of possible implementations of the cross-site scripting attack.

This issue is not a typical software security flaw where the remediation effort constitutes nothing more than applying a patch to the existing software. Due to the large number of possible ways that code can be written for websites, there are currently no automation tools available to assist in combating this issue. The remediation effort will be manual in nature and must necessarily result in adjustments to normal web development policies for all organizations.

Microsoft is working with the CERT Coordination Center at Carnegie-Mellon University and a cross-industry group representing the Internet community to address this issue. For further information about this issue please visit the CERT website at https://www.cert.org or the Microsoft TechNet Security Web site at https://www.microsoft.com/technet/security/default.mspx.

Disclaimer

© 2000 Microsoft Corporation. All rights reserved. This material is provided for informational purposes only on an AS-IS basis without warranty of any kind. MICROSOFT DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT.