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

                  Originally Posted: February 17, 2000
                  Last Updated: February 17, 2000

                  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 
                       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
                  This issue does not directly affect any version of the JRun Server. However, it 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
                  1) Allaire Forums customers running ColdFusion 4.01 or higher should add the following code to
                  the bottom of the /Forums/Application.cfm file. In this way it "treats" the critical form
                  variables from all forms to filter Allaire Forums Form variable input. 

                  . . .
                  <cfif ParameterExists(Form.FieldNames)>
                   <!--- force listed fields to be numbers --->
                  <cfloop 
                  list="Message_ID,Thread_ID,hidMessage_ID,hidThread_ID,hidReplyLevel,hidParentMessage_ID"
                  index="field">
                   <cfscript>
                    if ( isDefined( '#field#' ) and not IsNumeric( Evaluate( '#field#' ) ) )
                    '#field#' = 0;
                   </cfscript>
                  </cfloop>
                  <!--- remove all 'dangerous' tags --->
                  <cfloop 
                  list="txtAuthor_required,txtAuthor,txtEmail,txtSubject,taMessage,onCancelURL,taSignature"
                  index="field">
                   <cfscript>
                    if ( IsDefined( '#field#' ) )
                      '#field#' = REReplaceNoCase(
                  Evaluate('#field#'),"</?(SCRIPT|EMBED|APPLET|OBJECT)[^>]*(>|$)", "","ALL" );
                   </cfscript> 
                  </cfloop>
                  <!--- remove all double quotes from onCancelURL --->
                  <cfscript>
                   if ( IsDefined( 'onCancelURL' ) )
                    onCancelURL = Replace( onCancelURL, """", "", "ALL" ) ;
                  </cfscript>
                  </cfif>
                  . . . 

                  This modification will also be available in the next maintenance release of Allaire Forums. 

                  2) 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@allaire.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.allaire.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.