This article was previously published under Q253119
Retired KB Content Disclaimer
This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.
This article describes how to identify and correct Active Server Pages (ASP) applications that are susceptible to Cross-Site Scripting Security Issues (CSSI). Only input that is not correctly validated or formatted makes your application vulnerable to attack.
The following steps help you identify and correct ASP applications that are susceptible to CSSI:
Look for ASP code that generates HTML to be displayed. ASP writes HTML to the output in two ways:
Determine whether the HTML output includes input parameters. These parameters can come from a variety of sources. The following list includes common input sources:
Do While Not rst.EOF Response.Write rst("myfield") & "<br>" rst.MoveNextLoop
Session and Application Variables
When you find ASP code that generates HTML using some input, you need to evaluate solutions for your specific application. The solutions below present some general concepts to help you begin prevention of CSSI.
Please note that when filtering or encoding, you need to specify a character set for your Web pages to ensure that your filter is checking for the appropriate special characters. The data inserted into your Web pages should filter out byte sequences that are considered special based on the specific character set (charset). A popular charset is ISO 8859-1, which is the default in early versions of HTML and HTTP. You must take into account localization issues when you change these parameters.
Use the HTMLEncode method to encode input parameters when generating display.
In general, most CSSI attacks can be prevented simply by using HTMLEncode on input parameters. Using HTMLEncode works by replacing characters that have special meanings in HTML to HTML variables that represent those characters; (for example, & = &, " = "). Please note that only the data needs to be encoded, and not the full strings.
HTTP_REFERER can be used to limit the domain from which requests can be submitted.
HTTP_REFERER returns a string that contains the URL of the original request when a redirect has occurred. Web servers can check the referrer field when they receive a filled-in form and reject it if it does not come from the right place. You can check the HTTP_REFERER in the following way:
<% If (Request.ServerVariables("HTTP_REFERER") = "") Or _ (Left(Request.ServerVariables("HTTP_REFERER"),42) <> _ "http://www.myserver.com/AppDir/mainfrm.asp") Then Response.Redirect "http://www.myserver.com/AppDir/mainfrm.asp" End If %>
NOTE: The referrer field has some limitations:
You risk blocking legitimate form submissions.
The link may come from an e-mail or bookmark that does not have a URL.
Browsers may deliberately clear the referrer field, such as during an HTTPS request.
Use URLEncode to encode URLs received as input parameters.
The URLEncode method applies URL encoding rules, including escape characters, to a specified string. You should encode incoming URLs before displaying them. Here is a sample for URLEncode:
For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base:
252985 How To Prevent Cross-Site Scripting Security Issues For Web Applications
253121 How To Review MTS/ASP Code for CSSI Vulnerability
253120 How To Review Visual InterDev Generated Code for CSSI Vulnerability
253117 How To Prevent Internet Explorer and Outlook Express CSSI Vulnerability
Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.