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
NoticeThis 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
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 problemThe 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.
RamificationsIf input to your dynamic Web pages is not validated, you may encounter the following problems:
PreventionThis 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 for special charactersEncode 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:
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 charactersFiltering 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:
The following code processes user input before storing it for later use.
Filter output based on input parameters for special charactersThis 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 dataWhile 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:
ConclusionIn conclusion, the following are key points to remember regarding the cross-site scripting security problem:
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.htmlFor more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/253117/ )Preventing Internet Explorer and Outlook Express cross-site scripting security issues
(http://support.microsoft.com/kb/253119/ )How to review ASP code for CSSI vulnerability
(http://support.microsoft.com/kb/253120/ )How to review Visual InterDev generated code for CSSI vulnerability
(http://support.microsoft.com/kb/253121/ )How to review MTS/ASP code for CSSI vulnerability