Accessibility
 
Icon or Spacer


Allaire Security Bulletin (ASB00-05)
Cross-Site Scripting Vulnerability Information for Allaire Customers

Originally Posted: February 17, 2000
Last Updated: June 28, 2001

Summary
Microsoft, CERT, Sun Microsystems and other web development software companies, as well as the FBI have identified a new type of security attack called "cross-site scripting" which is based on common website design flaws and data manipulation that web browsers use when communicating with web servers. While the problem is not a vendor-specific issue, it does affect many web servers and virtually all web browsers currently in use. The problem lies with the design and coding techniques of web sites that serve dynamically generated HTML pages rather than the software the websites themselves run on.

Issue
Cross-site scripting can introduce security risks in dynamically generated HTML pages if browser-submitted input is not properly validated before it is reused as part of a dynamically generated HTML page back to out to the browser. Additionally, the problem can arise even when browser inputs are validated, if web developers store browser-submitted input data for generating a dynamic HTML page at some later time. This can occur if this stored data is not validated and stripped of special characters and tags before being included in a dynamically generated HTML page.

A malicious user is able to embed a script within browser-submitted input to a server-side script, which re-uses the input to dynamically generate an HTML page, so that it appears to browsers as originating from a trusted source. Users and developers should realize this is not a new vulnerability. This particular problem has existed for years, and happens only when applications do not adequately validate end-user input.

The underlying problem is that many web sites dynamically generate HTML pages and display non-validated input. If input from browsers is not validated, malicious users can embed scripts within the input. If a server-side script then re-displays this non-validated input, any HTML-embedded browser-side scripts will run on any browser requesting the generated HTML page, as though the trusted site generated it. Browser-submitted input can include Cookies, URL variables or Form variables.

If you do not validate input to your dynamic web pages, you may encounter the following:

  • Compromised data integrity s
  • Cookies set and read by unauthorized users
  • Intercepted user input
  • Malicious scripts executed by the client in the context of the trusted source

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

Presented here are a few approaches to preventing cross-site scripting security attacks. While these approaches can help you determine risk on your site, you must 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 incoming browser input sources, such as Cookies, URL and Form variables. Prevention means following good coding practices by validating all client browser input to your server-side code.

Affected Software Versions
· Allaire Forums
This problem affects Allaire Forums. Code and instructions to filter browser Form variable input is listed in the

"What Customers Should Do" section below.

· ColdFusion Server
This issue does not directly affect any version of ColdFusion Server. However, it can affect ColdFusion Server applications that do not validate browser input. Users need to review their code for areas of their web application that may be vulnerable. Several coding examples can be found in Allaire Security Best Practices Article #14558. These examples demonstrate how you might strip suspect characters and tags from browser input and output in ColdFusion template pages.

· JRun Server
A problem was discovered in JRun versions 3.0 and 2.3.3 where a SCRIPT tag could be executed in a client browser under certain conditions. Full details on this, including a patch, can be found in MPSB01-06. Still, this can affect JRun Server applications that do not validate browser input. Users need to review their code for areas of their web application that may be vulnerable. A coding example can be found in Allaire Security Best Practices Article #14558. This example demonstrates how you might strip suspect characters from browser input in Java Servlets and JSP pages.

· Allaire Visual Tools
Allaire's visual tools include several site creation wizards that help beginning developers generate useful site templates. These templates are not meant to be published to a production website without the developer taking the proper precautions of securing, testing, and enhancing the site. However, specific site wizards that might generate code where browser input is not automatically validated are:

  ·  The Drill Down Wizard
  ·  The Mailing List Wizard
  ·  The Record Viewer Wizard
  ·  The Library Wizard

Allaire recommends that developers review any auto-generated code for possible vulnerabilities. How to review your code for possible vulnerabilities is outlined the "What Customers Should Do" section below.

· Allaire Spectra
The Spectra Webtop management application contains multiple areas, which do not filter incoming browser inputs for special characters or tags, but since the Webtop relies on a secure user interface model, only trusted, validated users can submit browser input with special characters or script tags. Content editors and reviewers regularly submit browser input from browsers in the Webtop to create and manage production site content. As trusted users have access to the site, administrators need to be sure of whom they grant system access.

The following Spectra sample applications were examined with the following results. Note that these applications serve as code examples that are designed as a learning aid and should be removed from a production server environment.

1) i-Build Sample Application:

  • Search Form: when inputting anything containing the "<" or">" characters the search returns an error and does not render the HTML based upon the input field.
  • When replacing URL variables used for searches (includes the drop down keyword search) with anything containing the "<" or">"characters the search returns an error and does not render an HTML based upon the input field.
  • All other input takes place in a trusted environment
  • i-Build default access will be limited to localhost (127.0.0.1) access for Spectra 1.01.
2) RestoreNet Sample Application:
  • It is possible to input malicious characters into form fields, so that the server passes this malicious code into the custom page that the end-user views. Developers should not use this or any sample application on a production server.
  • RestoreNet default access will be limited to localhost (127.0.0.1) access for Spectra 1.01.
3) Allaire Spectra Visual Tools:
  • The Spectra Studio visual tools plug-ins operate based upon a trusted connection, requiring an authorized user to use them.

What Allaire is Doing
Allaire has published this bulletin notifying customers of the problem. Allaire has also released a new ColdFusion custom tag that users can use to strip unwanted strings, characters and tags from a given data string.

This tag is available for download and inspection here; the source is also available so that users can modify it to suit their needs. Allaire has also published information regarding resources already available in the CFML language to help with this issue, and responded individually to each of the products it publishes. Allaire recommends that users educate themselves about the coding issues and take steps necessary to protect themselves.

What Customers Should Do
 All Allaire customers should review the following information closely and make appropriate changes to their site code.

ColdFusion has certain tags and functions available to developers that allow you to obfuscate certain characters and strings so that web site browsers cannot easily modify or understand the strings. You can also use these to escape certain characters. Several of these as well as some generally recommended techniques for Java, ColdFusion and HTML developers are listed below.

Developers should review and make use of these techniques, tags and functions in appropriate areas of their web applications to help protect against malicious input. Note that it is up to web developers to review their code and decide which techniques, tags and functions are best for the affected areas of their application.

For more detail on each of the items, please see Allaire Security Best Practices Article #14558.

  • Review server-side JRun and ColdFusion code for possible areas of vulnerability
  • Define a Character Set in output HTML
  • Use built-in CFML tags and functions, such as:
    • HTMLCodeFormat
    • HTMLEditFormat
    • URLEncodedFormat
    • URLDecode
    • ReplaceList
    • REReplace
    • REReplaceNoCase
  • Escape and replace special characters and tags content in Java
  • Study the CF_INPUTFILTER ColdFusion CFML custom tag accompanying this Article and consider using similar techniques in your Application.cfm files

The cf_inputFilter tag removes characters or tags from all fields coming from the specified scopes (form, cookie, or URL). This tag can be placed in the Application.cfm file to filter out any input coming through these scopes to any of the templates belonging to the application.cfm file.

Download the Input Filter Tag

Note: Allaire has also released the CFML source code for this tag so that end-users may have an example of techniques used to remove special characters and tags from strings. As with the other solutions, there can be drawbacks. Please also note that this tag is provided "as is" and is provided for informational purposes only.

ColdFusion developers need to decide which solution best fit their needs; no foolproof quick fix exists to this problem. Each solution has certain drawbacks, whether it is a decrease in application performance, or inoperability in some areas. The following is a list of additional resources, which can provide additional information on the cross-site scripting issue:

Additional Issue Resources:

Original CERT advisory:

http://www.cert.org/advisories/CA-2000-02.html

Detailed instructions to disable scripting languages in your browser are available from the following "Malicious Code FAQ". Note that this solution only disables web browser scripting; it does not affect the viewing sites powered by ColdFusion, JRun or Spectra, as these are server-side technologies. However, if a site depends on sending JavaScript to the browser, pages may not render properly if web browser scripting is disabled. Developers should be sure to detect and accommodate users without browser scripting enabled. http://www.cert.org/tech_tips/malicious_code_FAQ.html

Since encoding and filtering data is such an important step in responding to this vulnerability, and because it is a complicated issue, the CERT/CC has written a document that explores this issue in more detail: http://www.cert.org/tech_tips/malicious_code_mitigation.html

Apache web server's "Cross-Site Scripting" release:
http://www.apache.org/info/css-security/

Apache-specific Information:
http://www.apache.org/info/css-security/apache_specific.html

Apache encoding examples:
http://www.apache.org/info/css-security/encoding_examples.html

Sun Microsystems' information regarding this issue:
http://www.sun.com/software/jwebserver/faq/jwsca-2000-02.html

Sun Microsystems' information on secure Java implementation:
http://java.sun.com/security/

Microsoft's information repository on this issue:
http://www.microsoft.com/technet/security/crssite.asp

Microsoft information for web developers:
http://www.microsoft.com/technet/support/kb.asp?ID=252985

Revisions
February 17, 2000 -- Bulletin first created.

Thanks to CERT, the Apache Software Foundation, Iris Associates, iPlanet, Microsoft Security Response Center, Microsoft Internet Explorer Security Team, and Microsoft Research.

Reporting Security Issues
Allaire is committed to addressing security issues and providing customers with the information on how they can protect themselves. If you identify what you believe may be a security issue with an Allaire product, please send an email to secure@macromedia.com. We will work to appropriately address and communicate the issue.

Receiving Security Bulletins
When Allaire becomes aware of a security issue that we believe significantly affects our products or customers, we will notify customers when appropriate. Typically this notification will be in the form of a security bulletin explaining the issue and the response. Allaire customers who would like to receive notification of new security bulletins when they are released can sign up for our security notification service. For additional information on security issues at Allaire, please visit the Security Zone at:
http://www.macromedia.com/security

THE INFORMATION PROVIDED BY ALLAIRE IN THIS BULLETIN IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. ALLAIRE DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL ALLAIRE CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF ALLAIRE CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.