This article describes how to identify and correct Microsoft Transaction Server/Active Server Pages (ASP) applications that are susceptible to cross-site scripting security issues (CSSI). Only input that is not correctly validated or formatted makes your application vulnerable to attack.
CSSI issues are rooted in the way an application handles data validation and formatting, so it is best tackled from the presentation layer.
This layer usually will consist of ASP pages, and occasionally it may include some components that assist in the rendering of HTML for the ASP page to display.
In the latter case it is important to note that although the application should perform the same operations to protect itself from CSSI as an ASP-only application, its physical implementation will cause some of the validating/formatting code to run in the ASP pages and some in the component. For detailed information on CSSI and ASP, please see the following Microsoft Knowledge Base article:
How to review ASP code for CSSI vulnerability
The following steps will help you identify and correct ASP applications susceptible to CSSI:
- Look for ASP or component code that generates HTML to be displayed. There are two typical scenarios:
- The component builds and returns an HTML string that ASP will write directly to the response.
- The component calls Response.Write internally to write directly to the page. Usually the Response object reference is obtained from the ObjectContext by calling GetObjectContext.Item("Response").
- Determine whether the HTML output includes application data. This data can come from a variety of sources, such as databases, files, cookies, other object variables, and so forth.
- Determine an appropriate solution. Having found ASP or component code that generates HTML using some input, you must determine an appropriate solution for your specific application. Solutions include (but are not limited to) validating/filtering invalid data or encoding it.
Guidelines for formatting
These guidelines will help you identify where to tackle formatting appropriately.
When writing information to a page, the specific application data must be HTMLEncoded. It is important not to HTMLEncode tags that are intended to end up in the HTML page. Therefore, if your component functions return HTML, the HTMLEncode has to be done inside them.
To HTMLEncode a string from a component, you need a reference to the ASP server object. You can obtain this reference from the MTS ObjectContext.Items collection:
sGoodHTML = GetObjectContext.Item("Server").HTMLEncode(sRawData)
: This code will generate table rows with values taken from a recordset. This code does not encode the output:
Do While Not oRecordset.EOF sHTML = sHTML & "<TR>" sHTML = sHTML & "<TD>" & oRecordset("FirstName") & "</TD>" sHTML = sHTML & "<TD>" & oRecordset("Address") & "</TD>" sHTML = sHTML & "</TR>" Loop
When this code is fixed, note that the values themselves are HTMLEncoded, rather than the whole HTML string:
Dim oServer As ASPTypeLibrary.ServerSet oServer = GetObjectContext.Item("Server")Do While Not oRecordset.EOF sHTML = sHTML & "<TR>" sHTML = sHTML & "<TD>" & oServer.HTMLEncode( oRecordset("FirstName")) & "</TD>" sHTML = sHTML & "<TD>" & oServer.HTMLEncode( oRecordset("Address")) & "</TD>" sHTML = sHTML & "</TR>" LoopSet oServer = Nothing
Note the use of the intermediate oServer
object reference. This is included to take advantage of early binding and to avoid resolving the ObjectContext.Item lookup every time. To declare an object as ASPTypeLibrary.Server, you must include a reference to "Microsoft Active Server Pages Object Library."
Please take into account the following guidelines:
- Business components should not call HTMLEncode (unless they are also rendering HTML). This is a task of the presentation layer.
- Generally, components using HTMLEncode or any of the ASP objects should run physically on the same computer as Internet Information Server (IIS).
- Solutions include (but are not limited to) validating input parameters and formatting input parameters.
For more information, see the following advisory from the Computer Emergency Response Team (CERT) at Carnegie Mellon University:
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
How to prevent cross-site scripting security issues for Web applications
How to review Visual InterDev generated code for CSSI vulnerability
How to prevent Internet Explorer and Outlook Express CSSI vulnerability