The ability to transform and inspect HTTP data as it flows in and out of a web application has many practical uses (both inside and outside of security). On IIS, this capability was historically restricted to ISAPI filters. Http Modules written in ASP.NET have always allowed processing of requests and responses to and from an ASP.NET application, but with the advent of IIS7 and the integrated ASP.NET pipeline, Http Modules written in ASP.NET now have access to virtually all stages of request processing (including those not handled by ASP.NET).

Transformer.NET is an Http Module designed for on-the-fly inbound and outbound url rewriting. Apache’s mod_rewrite, used to manipulate inbound request urls, is arguably one of the most popular Apache modules around. While there have been several ports of mod_rewrite to IIS (with implementations ranging from Http Modules to ISAPIs), they all share one shortcoming in common with their Apache predecessor: They only rewrite requests and not urls within outbound responses (such as links that are generated within an HTML page).

This has long been a pet peeve of mine. If you want to use mod_rewrite, you typically need to update the underlying website source code so that the hyperlinks within the application point to the “rewritten” urls. This can be a major effort and inconvenience if the site is already written, and even worse, it may not be possible for 3rd party or COTS web applications.

The initial beta release of Transformer.NET differs from previous rewrite modules because it supports bi-directional (inbound and outbound) url rewriting. Bi-directional rewriting eliminates the need to modify the underlying website code, which is great for legacy or third party web sites and applications. In addition to the ability to parse response content (such as HTML), Transformer.NET also includes the following two key internal mechanisms:

The bi-directional rewriting capability of Transformer.NET was really an initial “proof-of-concept” for us to start building bi-directional HTTP inspection and transformation solutions to solve some very interesting web application security problems.

Unlike Apache’s mod_rewrite, Transformer.NET does not implement conditional rewrites (ala mod_rewrite’s RewriteCond) so it is not intended to be a total port. The current beta version can be downloaded from our tools page. Transformer works on IIS6 (limited to ASP.NET applications) and with any site running on IIS7. A detailed user guide is included with the download.

I wrote a plug-in for Burp Proxy that decompresses HTTP response content in the ZLIB (RFC1950) and DEFLATE (RFC1951) compression data formats. This arose out of an immediate need on a recent web application security assessment.

Inspecting the HTTP traffic between client and server of the application under review, it appeared that most of the response bodies were compressed and unfortunately not being decoded by Burp (despite the “unpack gzip” option being enabled). The client, a Java applet, relied on response data for a lot of interesting functionality (including access control) and having the ability to easily view and manipulate the contents in plaintext before being received by the applet was clearly beneficial (let’s ignore the obvious client-side security issue here – this is a topic for another discussion).

As I mentioned earlier, it appeared the response content was compressed; however the expected Content-Encoding HTTP response header was not present. Inspection of the de-compiled Java applet code confirmed that compression was being performed with the java.util.zip.Deflater and java.util.zip.Inflater classes. At present, Burp Proxy does not support the ZLIB and DEFLATE compression formats (only GZIP compression is supported).

Burp is an essential tool in any web app testing toolkit and extending its functionality to inflate “deflate” compressed response content via the handy IBurpExtender interface seemed a worthwhile contribution. I hope others find the plug-in useful as well; at a minimum, it will be useful when the application returns for a round of regression testing.

The Burp plug-in can be downloaded here.

Also included with the download is an example servlet called “DeflateTestServlet” for generating HTTP responses bodies in the RFC1950 and RFC1951 compressed formats for testing the plug-in.

Also, here’s a good link that may help clarify your understanding of the compression formats used with HTTP.

I’ve just uploaded the latest version of AntiXSS for Java (version 0.02) to the GDS Tools page. What is AntiXSS for Java? Its a port to Java of the Microsoft Anti-Cross Site Scripting (AntiXSS) v1.5 library for .NET applications.

For those not familiar with the Microsoft AntiXSS library, it is an output encoding library for avoiding Cross Site Scripting vulnerabilities. Specifically it is intended to safely encode information written to the user’s browser within a specific context (i.e. if writing a string into the HTML of a page, you need to use the correct function - HtmlEncode). Unlike some other solutions the library implements a white listing approach, and encodes everything except characters known to be harmless. For example, the string <script> will be HTML encoded as <script>.

AntiXSS for Java was largely written as an educational exercise on my part, and as such the library should be considered “beta quality”, however it should be fairly usable for most applications. The library requires Java 1.4 or higher, but has no other prerequisites.

Usage:

• AntiXSS for Java comes as a source package, or alternatively you can just download the compiled Jar file. An Ant buildfile and JUnit tests are included with the source code.
• Put AntiXSS.jar somewhere in your CLASSPATH
• In your code, import com.gdssecurity.utils.AntiXSS
• All of the output filtering methods are implemented statically, so just wrap your calls to output functions in a call to one of the filtering methods (identical to the methods in the Microsoft library):
  1. HtmlEncode() - a string to be used in HTML. This method will return characters a-z, A-Z, 0-9, full stop, comma, dash and underscore unencoded, and encode all other characters in decimal HTML entity format (i.e. < is encoded as &#60;).
  2. UrlEncode() - a string to be used in a URL. This method will return characters a-z, A-Z, 0-9, full stop, dash, and underscore unencoded, and encode all other characters in short hexadecimal URL notation for non-unicode characters (i.e. < is encoded as %3c), and as unicode hexadecimal notation for unicode characters (i.e. %u0177).
  3. HtmlAttributeEncode() - a string to be used in an HTML attribute. This method will return characters a-z, A-Z, 0-9, full stop, comma, dash and underscore unencoded, and encode all other characters in decimal HTML entity format (i.e. < is encoded as &#60;).
  4. JavaScriptEncode() - a string safe to use directly in JavaScript. This method will return characters a-z, A-Z, space, 0-9, full stop, comma, dash, and underscore unencoded, and encode all other characters in a 2 digit hexadecimal escaped format for non-unicode characters (e.g. \x17), and in a 4 digit unicode format for unicode characters (e.g. \u0177).
  5. VisualBasicScriptEncodeString() - a string to use directly in VBScript. This method will return characters a-z, A-Z, space, 0-9, full stop, comma, dash, and underscore unencoded (each substring enclosed in double quotes), and encode all other characters in concatenated calls to chrw(). e.g. foo’ will be encoded as “foo”&chrw(39).
  6. XmlEncode() - a string to be used in XML. This method will return characters a-z, A-Z, 0-9, full stop, comma, dash and underscore unencoded, and encode all other characters in decimal entity format (i.e. < is encoded as &#60;).
  7. XmlAttributeEncode() - a string to be used in an XML attribute. This method will return characters a-z, A-Z, 0-9, full stop, comma, dash and underscore unencoded, and encode all other character in decimal entity format (i.e. < is encoded as &#60;).

For those of you familiar with output encoding, this library is functionally the same as the OWASP Reform library by Michael Eddington, which is not too surprising as I believe Michael was involved in developing the Microsoft AntiXSS library.

Any feedback, and especially bug reports, welcome.