[Owasp-leaders] OWASP Proxy

Rogan Dawes lists at dawes.za.net
Sun Dec 14 03:10:17 EST 2008


Daniel Cuthbert wrote:
>> Hi Rogan
>>
>> I'm not sure if this project is in the same vein as the OWASP  
>> WebScarab?
>>
>> Thanks
>> -- 
>> Nam

> Nam,
> 
> Rogan is responsible for Scarab as well. The issue we find when  
> testing is that common proxies, such as squid etc, often mangle the  
> traffic passing through it. Often we don't want this to happen, so  
> Rogan put his skills to use and created this proxy.
> 
> An ideal situation would be when testing has to be performed from a  
> central location, like
> 

> 
> This way, each tester can use their own choice of proxy, but have the  
> knowledge that their requests are not being changed by the central  
> proxy.

Actually, that is not the intention of this proxy at all.

The OWASP Proxy is intended as a library that can be used by developers
of tools like WebScarab, so that they don't have to reinvent the wheel.

As mentioned in my original mail, some people are taking the proxy
classes from WebScarab and wrapping their own code around them.
Unfortunately for them, WebScarab's proxy was never designed for this,
and consequently they had to mess around with a bunch of dependencies
that the WebScarab proxy class requires, but that they had no need for
themselves.

WebScarab's proxy and HttpClient implementation were also not as
"binary-clean" as some people would have liked. For example, while
parsing message headers, WebScarab would normalise "Host:  host" (note
two spaces between ":" and "host") back to "Host: host" (only one
space). For some people, that was a big deal, and prevented them from
using WebScarab entirely. Amongst other things, it meant that WebScarab
was unsuited to testing client-side vulnerabilities. OWASP Proxy uses a
byte[] to represent the entire message that is sent between client and
server and vice versa, and then layers more friendly methods for
accessing specific message properties on top of that.

So, OWASP Proxy is intended to address these issues. It is a small (45kB
jar) library (not a stand-alone executable) that Java developers can use
when they need to add intercepting or logging proxy capabilities to
their own programs.

OWASP WebScarab-NG will be rewritten around this library as time permits.

For interested people, the simplest proxy would look something like:

import org.owasp.proxy.daemon.Listener;

Listener l = new Listener(8008);
new Thread(l).start();

// wait until told to exit

l.stop();

This obviously has no customisation, though.

To customise the listener, extend the Listener class:

public class MyListener extends Listener {

  public MyListener(int port) throws IOEception {
    super(port);
  }

  @Override
  protected Response requestReceived(Request request)
    throws MessageFormatException {
    request.deleteHeader("Accept-encoding");
    return null;
  }

}

This example disables transfer of gzip or deflated content, by
preventing the Accept-Encoding header from reaching the server.

Similarly, one can intercept responses by overriding two methods:

  @Override
  protected boolean responseHeaderReceived(Conversation conversation)
    throws MessageFormatException {
    return false; // default is true
  }

  @Override
  protected void responseContentReceived(Conversation conversation,
    boolean streamed) throws MessageFormatException {
    conversation.getResponse().deleteHeader("Set-Cookie");
  }

One overrides "responseHeaderReceived" to return false to disable
response content streaming. OWASP Proxy defaults to streaming response
contents to the client as chunks are read from the server. This makes
the proxy more responsive, as the response content does not have to be
buffered in the proxy before being sent to the client. However, if you
want to modify the response in some way, you don't want it being
streamed to the client before you can modify it.

"responseContentReceived" is called once the entire response has been
read from the server. If the "streamed" parameter is false, (resulting
from responseHeaderReceived), then it is possible to modify the response
and have that modified response returned to the client.

At this stage, it is not possible to modify the response headers in
"responseHeaderReceived". This is a limitation that I'd like to remove.
With any luck, it should not prove to be too difficult. Naturally,
caution should be exercised when modify response headers if the content
has not yet been read, as it could change the way in which the response
content is interpreted by the OWASP Proxy. e.g. removing a
"Transfer-Encoding: chunked" header!

As you can see, I'm quite happy to discuss the OWASP Proxy with
interested parties! I look forward to your feedback.

Rogan


More information about the OWASP-Leaders mailing list