[Owasp-proxy] Interceptor

[Rogan Dawes]

On 2010/05/21 2:48 PM, Martin Holst Swende wrote:
> On 05/21/2010 01:27 AM, Rogan Dawes wrote:
>> On 2010/05/21 3:44 AM, Martin Holst Swende wrote:
>>
>>> I am pretty close to finishing up on the interceptor-part of the UI. I
>>> removed the jython-dependencies and
>>> made it pure Java instead.
>>>
>> Nice!
>>
>>
>>> However, I would like to intercept requests before the
>>> HttpProxyConnectionHandler does the "extractTargetFromResource" on them,
>>> since after
>>> that is done the request line is "GET /foo HTTP/1.1" instead of "GET
>>> HTTP://foo.com/foo..." which is not ideal. I have implemented the
>>> interceptor as a InterceptingMessageBuffer which is a subclass of
>>> BufferedMessageInterceptor. I can't seem to just jack it in before
>>> the HPCH does its thing. What would be the best solution?
>>>
>> The reasoning behind this change was to make the request as close to
>> what is sent over the wire to the target as possible. By stripping out
>> the target information as early as possible, it becomes feasible to send
>> arbitrary HTTP-style messages to any port.
>>
>> For example, OWASP Proxy should "just work" to intercept Squid ICCP
>> messages, which look like HTTP, even though they use a different protocol.
>>
>> It also means that one can send a completely malformed request to the
>> target, excluding even a valid request line (which is a requirement of
>> WebScarab, because the target information needs to be parsed from it).
>>
>> Unfortunately, going from "GET http://example.com/" to
>> "(target=example.com:80, ssl=false) GET /" does not allow us to go back
>> to the original fully qualified URL, other than by using heuristics
>> based on the port number for example.
>>
>> Which, if you are writing a tool aimed solely at HTTP, would not be
>> entirely unreasonable, I guess.
>>
>> Would recontructing the request using that heuristic not work for you?
>>
>> It's a bit of a trade off, I know, but I believe that the current
>> decision is the right one, perhaps it just hadn't been explained
>> adequately yet.
>>
> Thanks!
>
> It is a solid reasoning, one that I can agree with totally. These are
> the things I am thinking about :
> * Intercepting fully qualified:
>      + Interoperability with burp/paros/webscarab - cut'n'paste
>      +May substitute 'manual request' - just capture a foo-request and
> paste from other session
>      - Is not the actual  "on the wire" data that goes to the web server
>      - Must be well-formed, to certain degree
> * Intercepting non-fully qualified:
>      + Does not need to be well-formed
>      - Host/port/ssl cannot be changed, at least not with a single
> cut'n'paste - additional UI field(s) are needed for that
>
> For many scenarios, FQ would be desired, since more often than not I
> want my proxy to send well-formed data, while other times I may want the
> non-FQ.
> To be able to play with FQ, I see these options:
> 1. As you say: Reconstruct the FQ, edit, and deconstruct again ->  send
> 2. Create another HPCH which takes e.g RequestEditorIF instance. The
> HPCH would do something like this in handleConnectio:
>
> if(editor != null)
>      request = editor.edit(request);
> if (!request.getResource().startsWith("/")) {
>                      extractTargetFromResource(request);
>                  } else if (target != null) {
>                      request.setTarget(target);
>                      request.setSsl(ssl);
>                  } else if (request.getHeader("Host") != null) {
>                      extractTargetFromHost(request);
>                      request.setSsl(ssl);
>                  } else {
>                      throw new MessageFormatException(
>                              "No idea where this request is going!", request
>                                      .getHeader());
>                  }
>
> Doing like 2 would eliminate some unnecessary steps.
>
> I will start with doing just Non-FQ intercept, but plan to add options
> to the interceptor so the user can select either "Early intercept (FQ)"
> or "Late intercept (NFQ)". I think that
> will be the best solution, for all kinds of uses.
>
> Regards,
> Martin

I agree that it may be useful to work with fully qualified requests, 
particularly for copy-n-paste purposes. I truly think that 
reconstructing the "resource" based on the target information is the 
best way to achieve this.

I'm not sure if you have taken a look at the BufferedMessageInterceptor 
interface or not?

The intention there is that you can choose what messages you want to 
intercept, and then do what you want with them. Whether what you want to 
do is reconstruct the message into a fully qualified form that can be 
cut and pasted, or present it in individual fields parsed out, is up to you.

But that was the intended location for that sort of customisation to be 
implemented. If it doesn't work adequately, then I need to reconsider, 
but I think that at that point, you have almost all the information that 
you require, other than the specific protocol (http, https, iccp, 
whatever), which could largely be inferred from the port/ssl (or 
configured manually).

Rogan