Export (0) Print
Expand All
Microsoft Root Certificate Program
Expand Minimize

Cross-Site Scripting: Frequently Asked Questions

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
On This Page

What's this issue about?
What's the scope of the vulnerability?
If this isn't a vulnerability in a Microsoft product, why are you discussing it?
What causes the vulnerability?
What is "script"?
What do you mean when you say "validate all inputs"?
It's well established that programs always need to validate user input before using it. Why are you treating this as a new issue?
What kind of web pages are affected?
What's a dynamic web page?
I didn't think it was possible for anything but the server to put content into a server-generated web page. How can this happen?
How would a malicious user embed the script?
Would it always be necessary for the user to click a link provided by the malicious user?
Isn't this ultimately a case of users running untrusted code?
What could the malicious code do?
What's the risk from the script accessing my cookies?
Can this attack be made persistent?
Can this attack spread from one site to others?
Can this attack spread between visitors to the same web site?
Could someone exploit this vulnerability accidentally?
Is this related to the "Script Injection" issues that have been discussed with regard to Internet mail services?
What can web users do to protect themselves?
What do web sites and web developers need to do?
Why can't vendors produce a patch that prevents servers from accepting script as input?
Why can't vendors produce a patch that prevents browsers from executing malicious script?
If neither the server nor the browser can prevent this problem, how can a web developer prevent it?
Where can I learn more about best practices for security?
How do I get technical support on this issue?

What's this issue about?

Microsoft has identified a security vulnerability that could affect many web sites and web users. The vulnerability is not the result of a defect in any Microsoft product, nor in any other vendor's product. Instead, it results from coding mistakes in web applications.

Microsoft is working with the CERT Coordination Center and other vendors to address this issue, and is providing the bulletin to explain the issue, highlight needed changes to web site applications, galvanize web sites into making these changes expeditiously, provide technical information for web sites and web site developers, and let customers know what they can do to protect themselves in the meantime.

What's the scope of the vulnerability?

This vulnerability could allow a malicious user to cause arbitrary code to run during another user's web session. The code could take any action on the user's computer that the web site was authorized to take; this could include monitoring the web session and forwarding information to a third party, running other code on the user's machine, and reading or writing cookies. The code could be made persistent, so that if the user returned to the web site again in the future, the code would begin running again.

The vulnerability cannot be "injected" into a web session; it can only occur if the user clicks on a hyperlink provided by the malicious user. The long-term solution to this problem is for web sites to ensure that the code on their sites performs adequate checking to prevent this problem. However, while this work is ongoing, there are a variety of temporary measures that customers can take if appropriate.

If this isn't a vulnerability in a Microsoft product, why are you discussing it?

This vulnerability could potentially affect a broad segment of web sites and customers. Our intent, and that of CERT and other members of the industry, is to provide information on the issue and help drive an initiative to eliminate it.

What causes the vulnerability?

The vulnerability results because, under certain circumstances, it is possible for a malicious user to insert script into the data being sent to a web server. If an application on the server generates a web page in response, it is possible that the script could be embedded within the page, and would run when processed by the user's browser.

Whether or not a web site is affected by the vulnerability depends entirely on the applications running on the web server. If they follow recommended practices, and validate all inputs before using them, the site would not be affected. However, an informal survey shows that a large number of web sites do not do so, and could be affected by the vulnerability.

What is "script"?

A script is a type of computer program frequently used in web programming. (Scripting languages include JavaScript, Perl, Tcl, and others). Scripts consist of text commands. Every time the script is instantiated, the commands are interpreted and executed; this is in contrast to compiled languages like C++, in which the text commands are converted to executable code one time, and the executable code is run thereafter. This fact is important in understanding this problem - one of the reasons why script languages are involved in this issue is because script can be entered in any field on a web page that will accept text.

What do you mean when you say "validate all inputs"?

Anytime a program accepts an input from a user, it should examine it to make sure that it is valid - that its length and content are appropriate. In the case of this vulnerability, an application could only be affected if it blindly used the information it received without vetting it first.

It's well established that programs always need to validate user input before using it. Why are you treating this as a new issue?

As a general coding practice, it's well-known that programs need to always validate inputs before using them. However, there are two elements of this issue that warrant advising customers about it. First, this practice appears to be infrequently followed, judging by a survey of sites currently on the web. Second, the potential impact of failing to rigorously follow this practice is much broader than previously understood.

What kind of web pages are affected?

Only dynamic web pages that are generated based on user input could be affected, and, even then, only if the coding practices discussed above have not been followed. Static pages are not affected by this vulnerability under any conditions.

What's a dynamic web page?

There are two types of web pages, static and dynamic. A static page has fixed content - the browser simply displays whatever was in the page the server generated. Static pages are not affected by this vulnerability. Dynamic pages contain both fixed content and executable content. When the browser receives a dynamic page, it processes the executable content in order to determine how to display the fixed content.

Dynamic pages provide for a much richer user experience. They allow web pages to be animated, to tailor how the content is displayed based on each user's preferences, and so forth. However, through Cross-Site Scripting, a malicious user might be able to introduce additional executable content, in the form of script, into a dynamic page. When such a page was sent to the browser, the script would execute on the user's computer with the permissions appropriate to the web site.

I didn't think it was possible for anything but the server to put content into a server-generated web page. How can this happen?

Actually, it happens all the time. Suppose you visited a search page on a web site. You would type the word you want to search for, submit the page to the server, and the server would generate a page containing the search results. For example, if you searched for "banana", the server might generate a page that says "I couldn't find the word ‘banana’". You've added content to the server-generated page - namely, the word "banana".

Now suppose that, instead of entering the word "banana", you entered valid script as the text to search for. For instance, suppose you entered "banana ‹SCRIPT› ‹Alert("Hello");› ‹/SCRIPT›". If the server blindly treated the input as text, it would search the site and generate a results page that included the entire string. When the browser processed the page, it would evaluate the script as an expression and print "Hello" in a dialogue box on your screen.

Note, however, that this scenario would only work if the search application blindly used whatever you had typed in, without examining it to see if was reasonable and appropriate input. If the implementer had, for instance, stripped out the non-alphanumeric data from the input, the angle brackets would have been removed, and the script could not be executed.

How would a malicious user embed the script?

It turns out that it's fairly easy for a malicious user to create a hyperlink that takes a user to a web page of the malicious user's choice and fills in one or more fields with arbitrary input, potentially including script. The real challenge in this attack lies in social engineering - how to entice the user into clicking on the link, how to set up the attack so that when the user clicks on the link, he goes someplace he expected to but doesn't notice that one field has been filled in, etc.

Would it always be necessary for the user to click a link provided by the malicious user?

No. In most cases, the user would need to click on a link. However, there are some cases - for example, if the user's e-mail reader is configured to automatically display certain types of e-mails - in which the user would not have to click a link. Attacks in the latter category can be prevented by configuring the mail reader appropriately, and the Quick Start Guide provides instructions for doing this.

Isn't this ultimately a case of users running untrusted code?

Yes. In the end, the malicious user must trick the other user into allowing his code to run, so in many ways this is similar to a Trojan horse attack. However, the methods for initiating the execution of the malicious user's attack lend themselves to being so well camouflaged that even a cautious user might not realize that he is causing code to run.

What could the malicious code do?

The malicious code could perform any action that the web site was allowed to take. If the web site were untrusted and the user had constrained what it was allowed to do, the script might be able to do very little. But if the site were trusted, it might be able to do a great deal. For instance, it could alter the data that's contained in the web pages, monitor the session and copy personal data to a third site, run certain types of local programs, or access the site's cookies - all potentially happening without any indication to the user.

What's the risk from the script accessing my cookies?

The malicious script could read the site's cookie on your machine and send the data to a third party. This could expose information about your web surfing habits. However, it's worth noting that a web site cannot access any other sites' cookies, so a Cross-Site Scripting attack using Web Site A could only access Web Site A's cookie. It could not expose the information from Web Site B's cookie on your machine.

Can this attack be made persistent?

Yes. It is possible for a malicious script to cause itself to be executed every time you visit the web site. For instance, if you visited Web Site A and a malicious user managed to introduce his script into your session, it would be possible for the script to make itself run every time you returned to Web Site A.

Can this attack spread from one site to others?

No. If you visited Web Site A and a malicious user managed to introduce his script into your session, there would be no way for the malicious script to spread to Web Site B. The malicious user would need to mount a new attack to introduce his script into a session with Web Site B.

Can this attack spread between visitors to the same web site?

No. If you visited Web Site A and were affected by this vulnerability, it would not have any effect on other people who visit Web Site A.

Could someone exploit this vulnerability accidentally?

No. Exploiting this vulnerability requires a very specific, deliberate set of actions. It could not be exploited accidentally.

Is this related to the "Script Injection" issues that have been discussed with regard to Internet mail services?

Yes. These issues are a single instance of the larger vulnerability. Internet-based email services have long recognized that script in their emails poses a security risk, because the script would run in the context of the mail service. As a result, most Internet-based mail services filter any script from emails.

What can web users do to protect themselves?

The long-term solution to this problem is for web sites to review their code and ensure that it properly filters script. However, the Quick Start Guide provides some temporary measures you can take while this is ongoing.

What do web sites and web developers need to do?

Web sites need to ensure that any code that solicits user input and generates dynamic web pages based on it always filters the input to ensure that it cannot include script. Microsoft will provide documentation on how to do this.

Why can't vendors produce a patch that prevents servers from accepting script as input?

The chief problem here is that the server can't always tell what constitutes script and what doesn't. The script will execute on the browser, and there could be additional scripting languages available there, different character sets in use, and so forth. Without knowing what the browser will consider to be script, the server cannot strip it out.

Why can't vendors produce a patch that prevents browsers from executing malicious script?

When a browser receives a page from the server containing script, there is no way to determine which, if any, of the script could have been inserted by a malicious user. It all appears to have come from the server.

If neither the server nor the browser can prevent this problem, how can a web developer prevent it?

The web developer has a crucial piece of information, namely, the context of the data that his application is soliciting. For instance, if a developer is creating a search page, he can restrict the input to alphanumeric characters only. The set of allowable characters for each field is different and depends on how it will be used - but only the developer is in a position to know this.

Where can I learn more about best practices for security?

The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?

Microsoft Technical Support can provide assistance with this or any other product support issue.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft