[Owasp-proxy] [Owasp-webscarab] Where to target new plugins - webscarab or webscarab-ng?

Rogan Dawes rogan at dawes.za.net
Sun Jun 13 15:07:23 EDT 2010

On 2010/06/13 8:33 PM, Martin Holst Swende wrote:
> On 06/12/2010 06:18 PM, Dave Sexton wrote:
>> Hi List,
> Hi!
>> Please excuse multiple different questions in one post..
>> I have recently been looking at a number of Java applet based
>> applications that communicate with the server by sending and receiving
>> serialised objects via HTTP. Nothing unusual about that.
>> Such serialised objects contain a lot of binary data and understanding
>> and monkeying around with the data in these - whilst possible at times -
>> is difficult to say the least. I realised that it would be a good
>> project to write an extension to Webscarab to decode and allow
>> modifications to be made during transport - much as we can do with
>> normal text-based messages. First question - has this already been done
>> (&  my Google-fu is not up to finding it)?
>> I'm a reasonably competent programmer, so writing this doesn't scare me
>> and the research I've done so far leads me to believe that this could be
>> approached either through the serialisation API or through the debugger
>> architecture (JPDA). Both are alien tech to me as far as going under the
>> hood with them is concerned, does anyone have any insight on the
>> direction to go?
> I have just recently started digging in the exact same area, but from
> another perspective. There is some documentation about
> the wire protocol, but I have not found any that is very good. In order
> to really go under the hood, I have been looking quite a lot
> on the OpenJDK RMI implementation, which is completely open source
> (except for some 1 percent or something like that).
> The JRMP protocol has, from what I understand, three modes
> (sub-protocols)[1].
> /StreamProtocol/
> /SingleOpProtocol/
> /MultiplexProtocol/
> "The /SingleOpProtocol/ is used for invocation embedded in HTTP
> requests, where interaction beyond a single request and response is not
> possible."
> It seems that the data you will be seeing over http, is
> SingleOpProtocol. I think it would be possible to write a plugin for
> webscarab for this. However, I think you can do a much better
> implementation if you implement all three protocols, i.e, NOT based on
> http. To do that, you would have to basically write another proxy which
> does not use http, but is a tcp-based transparent forward proxy.
> That sounds like a pretty big project, I admit, but I'm thinking about
> whether it may be possible to use parts of the owasp proxy for this.
> Rogan, do you have any input? For example, would it not be possible to
> just replace HttpProxyConnectionHandler wit something like a
> "RmiTcpConnectionHandler" and keep the general architecture?
> As I see it, the drawbacks using webscarab is:
> - You still need to create a lot of new UI, not much you can reuse
> - You will only be able to decode SingleOpProtocol over http
> Owasp proxy:
> - You will still need to create a lot of new UI*
> - Probably possible to capture (and modify) non-http based data
> * I have written an interceptor for the owasp proxy, you may be able to
> reuse large parts of my stuff and get a basic UI going - just like
> webscarab would provide you with.
> I think a trapper for RMI would be awesome, good luck with it!
> Some links:
> [1] http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-protocol3.html
> http://java.sun.com/javase/6/docs/platform/serialization/spec/serialTOC.html
>> Finally, there is the question of which version of scarab to target. The
>> NG git tree doesn't seem to have been touched in a year. Is NG pretty
>> much dead in the water now?
>> TIA
> As far as I understand, yes, it has been dropped in favour of the Owasp
> Proxy.
> Regards ,
> Martin

Hi Dave, Martin,

To be entirely honest with all parties, WebScarab is largely in 
maintenance mode. WebScarab-NG was an attempt at creating a more 
usable/discoverable version of WebScarab, but several bad design choices 
(use of Apache HttpClient being one of them) has led to -NG stagnating.

One way forward for -NG is to port it to use the OWASP Proxy 
underpinnings, as well as the OWASP Proxy HttpClient code. It is a fair 
sized undertaking, one which I have not even tried to start.

The limited time I do have for coding has been given to OWASP Proxy, 
which is pretty functional, for what it does. That said, I am 
contemplating some architectural changes to OP to allow it to support 
new features in HTML5, such as WebSockets, as well as supporting NIO 
(event-driven code).

My intention with the new approach is to define a protocol handler 
class, e.g. HttpProtocolHandler, that creates suitable Request and 
Response classes to contain the actual request data as it is received, 
and notifies suitable user-provided implementations when a usable chunk 
of data has been received.



requestContentReceived may be called several times, depending on the 
size of the request content. The handler would then decide whether to 
buffer the data, or to stream it on.

This approach should then also allow implementation of other arbitrary 
protocols, e.g. interception of unspecified bidirectional TCP 
connections, with the decision to forward a chunk of data in either 
direction made by the human operator when the data received appears to 
be complete, and appropriate edits may have been performed.

And as mentioned above, this should allow support of WebSockets, using a 
suitable WebSockets protocol handler, wrapped within an HttpProtocolHandler.

Hopefully this approach would also suffice for intercepting RMI 
connections, and deciphering them, given sufficient detail of the RMI 
protocol to allow implementation of an RMI protocol handler.

That said, from what Dave posted, he is looking at serialized objects, 
rather than actual RMI invocation necessarily. You may be able to 
deserialise the object within any of the proxies (you might want to try 
prototype it in the WebScarab BeanShell plugin), and then display the 
object using something like the Java Object Inspector (JOI). After 
editing, it could then be re-serialised, and forwarded on to the consumer.

Not sure if this mail has helped at all.



More information about the Owasp-proxy-project mailing list