[Owasp-leaders] OWASP Proxy

Daniel Cuthbert daniel.cuthbert at owasp.org
Sun Dec 14 03:24:27 EST 2008


That'll teach me for doing geek stuff on the weekend... back to art!


On 14 Dec 2008, at 10:10 AM, Rogan Dawes wrote:

> 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
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders



More information about the OWASP-Leaders mailing list