Advisory: Cross-Site Scripting Vulnerability Information for Allaire Customers
Advisory: Cross-Site Scripting Vulnerability Information for Allaire Customers:
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 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.
. . .
if ( isDefined( field ) and not IsNumeric( Evaluate(
field ) ) )
'#field#' = 0 ;
if ( IsDefined( field ) )
'#field#' = REReplaceNoCase( Evaluate(field),
"]*(>|$)", "", "ALL"
) ;
if ( IsDefined( 'onCancelURL' ) )
onCancelURL = Replace( onCancelURL, """", "", "ALL" )
;
. . .
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.
留言
張貼留言