How to prevent cross-site scripting security issues

Article ID: 252985 - View products that this article applies to.
This article was previously published under Q252985
Notice
This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center
(http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fwin2000)
is a starting point for planning your migration strategy from Windows 2000. For more information see the Microsoft Support Lifecycle Policy
(http://support.microsoft.com/lifecycle/)
.
Expand all | Collapse all

On This Page

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.
Back to the top | Give Feedback

MORE INFORMATION

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("<a href=\"" + BaseUrl +
      Server.URLEncode(Request.QueryString("SearchString")) +
      "\">click-me</a>");
%>
<% Response.Write("Hello visitor <I>" +
      Server.HTMLEncode(Request.Form("UserName")) +
      "</I>");
%>
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 <TEXT> 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 <TABLE> elements, a generic function that removes the special characters would strip the < and > characters, which ruins the <TABLE> 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.
Back to the top | Give Feedback

REFERENCES

For more information, see the following advisory from the Computer Emergency Response Team (CERT) at Carnegie Mellon University:
http://www.cert.org/advisories/CA-2000-02.html
(http://www.cert.org/advisories/CA-2000-02.html)
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
253117
(http://support.microsoft.com/kb/253117/ )
Preventing Internet Explorer and Outlook Express cross-site scripting security issues
253119
(http://support.microsoft.com/kb/253119/ )
How to review ASP code for CSSI vulnerability
253120
(http://support.microsoft.com/kb/253120/ )
How to review Visual InterDev generated code for CSSI vulnerability
253121
(http://support.microsoft.com/kb/253121/ )
How to review MTS/ASP code for CSSI vulnerability
Back to the top | Give Feedback

Properties

Article ID: 252985 - Last Review: March 1, 2006 - Revision: 3.6
APPLIES TO
  • Microsoft Active Server Pages 2.0
  • Microsoft Active Server Pages 3.0
  • Microsoft Windows 2000 Server
Keywords: 
kbcodesnippet kbcssi kbhowto kbsecurity KB252985
Back to the top | Give Feedback

Give Feedback

 
Back to the topBack to the top