Microsoft KB Archive/252985

= How to prevent cross-site scripting security issues =

Article ID: 252985

Article Last Modified on 3/1/2006

-

APPLIES TO


 * Microsoft Active Server Pages 2.0
 * Microsoft Active Server Pages 3.0

-



This article was previously published under Q252985



SUMMARY
Dynamically generated HTML pages can introduce security risks if inputs are not validated either on the way in or on the way out. Malicious script can be embedded within input that is submitted to Web pages and appear to browsers as originating from a trusted source. This problem is referred to as a cross-site scripting security issue. This article discusses cross-site scripting security issues, the ramifications, and prevention.



The problem
The underlying problem is that many Web pages display input that is not validated. If input is not validated, malicious script can be embedded within the input. If a server-side script then displays this non-validated input, the script runs on the browser as though the trusted site generated it.

Ramifications
If input to your dynamic Web pages is not validated, you may encounter the following problems:
 * Data integrity can be compromised.
 * Cookies can be set and read.
 * User input can be intercepted.
 * Malicious scripts can be executed by the client in the context of the trusted source.

Which Web pages are at risk? Essentially, the problem affects dynamic page creation based on input that was not validated. Typical examples include the following types of Web pages:
 * Search engines that return results pages based on user input.
 * Login pages that store user accounts in databases, cookies, and so forth and later write the user name out to the client.
 * Web forms that process credit card information.

Prevention
This section presents a few approaches to preventing cross-site scripting security attacks. Evaluate your specific situation to determine which techniques will work best for you. It is important to note that in all techniques, you are validating data that you receive from input and not your trusted script. Essentially, prevention means that you follow good coding practice by running sanity checks on your input to your routines.

The following list outlines the general approaches to prevent cross-site scripting attacks:
 * Encode output based on input parameters.
 * Filter input parameters for special characters.
 * Filter output based on input parameters for special characters.

When you filter or encode, you must specify a character set for your Web pages to ensure that your filter is checking for the appropriate special characters. The data that is inserted into your Web pages should filter out byte sequences that are considered special based on the specific character set. A popular charset is ISO 8859-1, which was the default in early versions of HTML and HTTP. You must take into account localization issues when you change these parameters.

Encode output based on input parameters for special characters
Encode data that is received as input when you write it out as HTML. This technique is effective on data that was not validated for some reason during input. By using techniques such as URLEncode and HTMLEncode, you can prevent malicious script from executing.

The following code snippets demonstrate how to use URLEncode and HTMLEncode from Active Server Pages (ASP) pages: <%     var BaseURL = http://www.mysite.com/search2.asp?searchagain=; Response.write("click-me"); %> <% Response.Write("Hello visitor " +     Server.HTMLEncode(Request.Form("UserName")) +      ""); %> If you encode the HTML and URLs, you may need to specify the code page as you would if you were to filter data.

It is important to note that calling HTMLEncode on the string that is about to be displayed will prevent any script in it from being executed and thus prevents the problem.

Filter input parameters for special characters
Filtering input works by removing some or all special characters from your input. Special characters are characters that enable script to be generated within an HTML stream. Special characters include the following: < > " ' % ; ) ( & + - Note that your individual situation may warrant the filtering of additional characters or strings beyond the special characters.

While filtering can be an effective technique, there are a few caveats:
 * Filtering may not be appropriate for some input. For example, in scenarios where you are receiving  input from an HTML form, you may instead choose a method such as encoding (see below).
 * Some filtered characters may actually be required input to server-side script.

The following sample filter, which is written in JavaScript, demonstrates how to remove special characters: function RemoveBad(strTemp) { strTemp = strTemp.replace(/\<|\>|\"|\'|\%|\;|\(|\)|\&|\+|\-/g,"");    return strTemp; } The following code processes user input before storing it for later use. <% Session("StoredPreference") = RemoveBad(Request.Cookies("UserColor"));         var TempStr = RemoveBad(Request.QueryString("UserName"));

Filter output based on input parameters for special characters
This technique is similar to filtering input except that you filter characters that are written out to the client. While this can be an effective technique, it may present a problem for Web pages that write out HTML elements.

For example, on a page that writes out  elements, a generic function that removes the special characters would strip the characters, which ruins the  tag. Therefore, in order for this technique to be useful, you would only filter data passed in or data that was previously entered by a user and stored in a database.

Possible sources of malicious data
While the problem applies to any page that uses input to dynamically generate HTML, the following are some possible sources of malicious data to help you spot check for potential security risks:
 * Query String
 * Cookies
 * Posted data
 * URLs and pieces of URLs, such as PATH_INFO
 * Data retrieved from users that is persisted in some fashion such as in a database

Conclusion
In conclusion, the following are key points to remember regarding the cross-site scripting security problem:
 * The problem affects dynamic page creation based on input that was not validated.
 * Omission of a sanity check on input data can have unexpected security implications. The problem is preventable through good development standards such as input validation.
 * You need to evaluate solutions on a per site, page, and even field basis and use a technique that makes sense.

