Microsoft KB Archive/253120

= How To Review Visual InterDev Generated Code for CSSI Vulnerability =

Article ID: 253120

Article Last Modified on 7/8/2005

-

APPLIES TO


 * Microsoft Visual InterDev 6.0 Standard Edition

-



This article was previously published under Q253120



SUMMARY
The following article discusses how to identify and correct Visual InterDev applications that are susceptible to CSSI (Cross-Site Scripting Security Issues). Only input which is not correctly validated or formatted makes your application vulnerable to attack.

This article focuses on Visual InterDev Design Time Controls (DTC) and the Script Library. For general guidelines regarding ASP code, please see the following Knowledge Base article:

253119 How To Review ASP Code for Vulnerability for CSSI



MORE INFORMATION
The Visual InterDev DTCs present unique challenges to developers because some of the code is generated automatically. A developer may not be familiar with the specific implementation of the script objects that are generated and any vulnerabilities of them or how to best address them. This article covers all the known issues with the various DTCs, and it also covers possible options for addressing those vulnerabilities.

The issues fall into two specific categories:
 * 1) DTCs that are scripted to display data from a database, and the database contains input from users.
 * 2) DTCs that are scripted to display or use data that was submitted from the client.

In both cases, proper validation and encoding of output values prevents a DTC-based page from being used in a CSSI attack.

When using any method of a DTC that retrieves information from that DTC (such as .getCaption, .getText, .Value), when the value was set using user supplied information, the resulting string is not HTMLEncoded. Also, some DTCs that can be bound to a database field display the raw information from the database without encoding. As such, you should HTMLEncode these values when displaying to a browser. For example: Response.Write Server.HTMLEncode(Textbox1.value) If the data is to be used as part of a URL, you should use URLEncode instead. For example: Response.Write "Click here!" Because there are multiple ways to encode entrusted scripting code characters, you should explicitly set the character set for the page the browser renders. You can do this by inserting a client-side  tag in between the  tags of your document. For example:  This can also be done from ASP using the Response.Charset property:

<% Response.Charset= "ISO-LATIN-1" %>

Here are some common examples:

Here are possible solutions for these examples:

The Grid DTC does not HTMLEncode values retrieved from a database. If your database takes user input (for example, a guestbook), you should HTMLEncode your output. This can be done by clicking the the Data tab in the Grid property dialog box, and typing: =Server.HTMLEncode([fieldname]) Where fieldname is the name of each field that is displayed for that column. Most DTCs automatically HTMLEncode data retrieved from a database when displaying; some do not. Those controls should make use of additional code to ensure that output to a client is properly HTMLEncoded.

NOTE: DTCs usually automatically implement the necessary logic to maintain their state during round trips to the server. In the case of the Textbox DTC for example, when the information is round tripped to the server, the Textbox.asp script library page correctly HTMLEncodes the contents of the text box in the process of maintaining the control's state.

