Microsoft, Sun Microsystems and other web development software companies, have identified a new type of 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.
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.
Allaire has 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.
. . .
<!--- force listed fields to be numbers --->
if ( isDefined( field ) and not IsNumeric( Evaluate( field ) ) )
'#field#' = 0 ;
<!--- remove all 'dangerous' tags --->
if ( IsDefined( field ) )
'#field#' = REReplaceNoCase( Evaluate(field), "</?(SCRIPT|EMBED|APPLET|OBJECT)[^>]*(>|$)", "", "ALL" ) ;
<!--- remove all double quotes from onCancelURL --->
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:
* 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.
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.