Twitter
Wednesday
Nov072007

Ruby port of Extended Scanner released

An old colleague of ours has just released a Ruby port of Extended Scanner on his blog at securitytechscience.com. If you're not familiar with it, Extended Scanner is a simple proof of concept web application scanner (in Perl) written by GDS co-founder Brian Holyfield for the book Network Security Tools.. The original Perl version can be found on our Tools download page here.

Quoting from his posting :-

The only thing I have added is the MySQL code as my demo app has a MySQL backend. Before I chat about this, the code can now perform the following:

  1. Validate SQL injection (i.e., reduces false positives)
  2. Enumerate backend database type (currently detects MS SQL, Oracle and MySQL)
  3. Enumerate the number of columns at the injection point
  4. Enumerate the data type of each column identified

Friday
Oct262007

Fortify Partner ' SCA 5.0 Sneak Peak

Just got through attending a Fortify webinar where J.B. demo'd the latest beta 5.0 version of SCA. Firstly, it was very impressive.

Language support has now been added for classic ASP, COBOL, JavaScript and PHP, along with several new analyzers, a couple of which are interestingly aimed at "deviation" and false path detection.

However, one of the most apparent changes is the continual evolution of Audit Workbench (AWB) from a predominantly result's only /verification tool towards a true one stop "work bench". This includes new "right-click" custom rule generation (complete with slick and more intuitive interface) which will dramatically speed up new rule generation based on what is appearing in the code. Of course, the ability to then easily re-run scans from within AWB follows on nicely to help verify new rule accuracy.

More detail to follow once we get our hands on a 5.0 beta version. The current full 5.0 release timeframe appears to be towards Dec/Jan, - further new feature information can be found on the Fortify site.

Tuesday
Oct092007

.NET Data-bound Web controls & (anti)XSS - Some Considerations

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("&nbsp;")))
tc.Text = AntiXss.HtlmEncode(tc.Text);
}

(Note - be careful not to double encode any &nbsp; values and blow out the control)

Page 1 ... 23 24 25 26 27