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

[Martin Holst Swende]

Hi,

[snip]
> 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.
>
> e.g.
>
> requestHeaderReceived
> requestContentReceived
> requestComplete
>
> 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.
>   
Sounds very good and usable. I guess NIO is a bit overkill for http, but
could be
good for generic tcp protocols.
> 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.
>   
A question about that, which may be a bit off-topic. If a serialized object
is *not* a common java object, such as the basic types, but e.g
"MyAppletUserId" wouldn't a
deserialization of that object using the native java serialization cause
classnotfoundexception,
since the java runtime will try to instantiate the object and fail,
since the compiled class
is not available?

But the same problem should also occur in that implementation for Burp,
I haven't looked
at how they solved that. I would have thought that one would have to
write a new serialisation
implementation based on the native one, but which does not try to load
the classes - instead just
place the values into some sort of container. But maybe I got it totally
wrong?
> Not sure if this mail has helped at all.
>   
> Regards,
>
> Rogan
>   

Definitely did! Thanks,
/Martin