Tuesday, October 9, 2007 At 11:09AM
We spend a lot of time helping clients fix XSS exposures as part of our secure remediation services. One common trend we observe repeatedly (and that triggered this posting today) revolves around the seemingly subconscious trust placed on data pulled from backend databases combined with a primary misconception around the use of many of the .NET data-bound controls.
Often, it is not understood where the majority of data used by an application originates from, and whether it was adequately vetted before being stored. Typically, many different applications, both Internet and Intranet facing, will all populate and pull from the same series of databases. Potentially tainted data retrieved is then often simply displayed by the consuming web application thus exposing unsuspecting users to XSS attack vectors.
Inconsistent .NET Data-bound control Encoding?!?
Unfortunately with regard to XSS, no encoding is performed by many of the .NET Data-bound controls (i.e. the DataGrid, DataList, RadioButtonList and CheckBoxList) when displaying data retrieved from a dynamic data source.
Subsequently, this has become a common trap in that the encoding for certain controls is the responsibility of the developer and the encoding requirements often vary for each control. This information has only been recently captured in the May 8, 2007 “Comments and Corrections” addendum of the superb Microsoft Patterns & Practices book Improving Web Application Security: Threats and Countermeasures, where the following valid recommendations are made complete with excellent code examples (which I build upon slightly below):
“For example, for a DataGrid control, you have the following options:
- Turn all columns into templates and manually use HtmlEncode()/UrlEncode() on each call to DataBinder.Eval
- Override one of its DataBinding methods, such as OnDatabinding or OnItemDataBound and perform encoding on its items.”
HtmlEncode/UrlEncode vs. the Microsoft Anti-Cross Site Scripting Library
The classic solution to fixing/preventing XSS has been to employ the use of the HtmlEncode/UrlEncode utilities (as above) to encode values before they are rendered to users. However the use of Microsoft Anti-Cross Site Scripting Library (currently v1.5) should warrant some heavy consideration to provide enhanced XSS protection for .NET applications. This library basically provides superior protection by encoding everything except a small set of “known safe” characters. This white-list approach is considered inherently more secure when compared against the classic HtmlEncode and UrlEncode utilities which encode only known bad items. As there seems to be no end of creative and new ways of exploiting XSS this tightened protection should be very appealing in .NET environments as part of a multilayer defensive approach. (Remember never to rely on a single security control; as it will nearly always be by-passable under certain conditions).
A prime example of how Version 1.5 of Microsoft Anti-Cross Site Scripting Library provides greater protection against XSS is illustrated via the availability of its JavaScriptEncode Encoding Method to protect vulnerable application values that are used directly within existing JavaScript blocks. Such values would still be vulnerable to XSS if they were only subjected to encoding via the classic HtmlEncode/UrlEncode utilities. (The XML Encoding methods XmlEncode and XmlAttributeEncode are also very useful as well). For those who require further information (or are rightly sceptical), the Microsoft ACE Team has an excellent description of the v1.5 enhancements, complete with tutorial, (which has also been endorsed by Microsoft Security leader Michael Howard). If you’re interested in seeing what’s going on under the hood ‘ examine the component yourself via Lutz Roeder’s Reflector tool as did Microsoft’s David Coe with an earlier version (among others).
Leveraging AntiXss and DataBinder.Eval to prevent DataGrid XSS
The following example pseudo code shows how the Microsoft Anti-Cross Site Scripting Library could be used manually on each call to DataBinder.Eval to prevent potential XSS exposure.
Pseudo code example 1:
<asp:datagrid id="grdFoo" CssClass="gridheader" runat="server" AutoGenerateColumns="False" ... <ItemTemplate> <a name="fooUrl" href='<%#AntiXss.HtmlAttributeEncode (DataBinder.Eval(Container.DataItem,"FooURL").ToString()) %>?FooID=<%#AntiXss.HtmlAttributeEncode (DataBinder.Eval(Container.DataItem,"FooId").ToString())%></a> </ItemTemplate>
Leveraging OnItemDataBound and AntiXss to prevent DataGrid XSS
The OnItemDataBound method provides the final opportunity to encode the data item to prevent any XSS before it is rendered to the remote user via the ItemDataBound event. The Microsoft Anti-Cross Site Scripting Library could be leveraged by the OnItemDataBound method at this point to encode all data items.
Pseudo code example 2:
<asp:datagrid id="grdFoo" CssClass="gridheader" runat="server" AutoGenerateColumns="False" OnItemDataBound="grdFoo_ItemDataBound"> protected void grdFoo_ItemDataBound(object sender, DataGridItemEventArgs e) foreach (TableCell tc in e.Item.Cells) { if (!string.IsNullOrEmpty(tc.Text) && !(tc.Text.Equals(" "))) tc.Text = AntiXss.HtlmEncode(tc.Text); }
(Note – be careful not to double encode any values and blow out the control)
Author: Andrew Nairn
©Aon plc 2023