Knowledge Base

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.

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 elements, a generic function that removes the special characters would strip the < and > 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.

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

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

253117 Preventing Internet Explorer and Outlook Express cross-site scripting security issues

253119 How to review ASP code for CSSI vulnerability

253120 How to review Visual InterDev generated code for CSSI vulnerability

253121 How to review MTS/ASP code for CSSI vulnerability

Keywords: kbhowto kbcssi kbcodesnippet kbsecurity KB252985

Microsoft KB Archive/252985

Contents