RSS Feed

Beta version of the new Burp Suite released

A quick note this morning - Portswigger has just released a beta version of the new Burp Suite. New features listed include:

  • Burp Sequencer - for analyzing the randonmness of session tokens
  • Burp Decoder - for decoding/encoding of data
  • Burp Comparer - for visually comparing two data items

Also included are a number of fixes and improvements. I'm downloading it to try it out now.


Early Look at Tracer 2.0 Beta 

So, continuing in the vein of testing Fortify's various Beta products (see Andrew's SCA 5.0 sneak peak), I recently got to work with the Fortify Tracer 2.0 beta, which I've gotta say was very interesting. If you're not familiar with Tracer, here's a little background - out of the box, Tracer inserts monitors into your deployable code, tracks all known inputs, and flags instances where the use of certain API's with those inputs are either un-validated or used in an insecure manner. This sets the table for more thorough coverage when you're performing Black Box testing. It is well known that many "set and forget" automated scanners almost never hit every available page which leads to gaps in testing and lots of frustration. Tracer fills those voids and is especially handy for performing Black Box app testing when in a time crunch.

Older releases of Tracer were ideally geared towards use by security professionals. However, with Tracer 2.0, the user only needs to be able to crawl the entire application. Whether it's manual or automated, no penetration testing procedures are needed. This is a bonus for those non-security professionals that want to be able to easliy add this tool to their pre-deployment check-list.

Another nice addition included in Tracer 2.0 is the increased ease of setting up the tool. Previously with Tracer 1.1, you would run the compile-time instrumentation against your J2EE executable (deployable WAR or EAR file) using the supplied command line tool. You would then have to manually deploy the WAR file that you just instrumented into your environment.

Example of 1.1 command line syntax:
C:\>tracer.bat -a Tomcat5 --appserver-home "C:\Program Files\Fortify Software\Fortify Tracer 1.1\Core\tomcat" --coverage "com.order.splc.*" splc.war

Tracer 2.0 Beta has made the instrumentation process MUCH easier. They've introduced a new method called "load-time weaving," where the monitors are introduced when the class files are loaded rather than before the application is deployed. This makes for a very fast instrumentation process and you don't have to redeploy your application anymore.

To instrument using load-time weaving, Tracer 2.0 comes with an app called Tracerltw (Figure 1). This web application allows you to just give it the web root directory of the application you want it to monitor. Users will find this point and click instrumentation much easier and more intuitive than the previous command line options.


Figure 1 ' Tracerltw application

Another nice feature is support for .NET applications. Previous releases were strictly limited to J2EE applications. In general, Fortify seems to be broadening their language coverage for all their products. Just look at SCA 5.0 and its support for 4 more languages.

This is a very green beta, so as new functionality comes out in future beta releases, I'll keep you updated.


Ruby port of Extended Scanner released

An old colleague of ours has just released a Ruby port of Extended Scanner on his blog at 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


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.


.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"
<a name="fooUrl" href='<%#AntiXss.HtmlAttributeEncode

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"


protected void grdFoo_ItemDataBound(object sender,
DataGridItemEventArgs e)

foreach (TableCell tc in e.Item.Cells)
if (!string.IsNullOrEmpty(tc.Text) &&
tc.Text = AntiXss.HtlmEncode(tc.Text);

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

Page 1 ... 26 27 28 29 30