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

[Rogan Dawes]

>> 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.

To be honest, it doesn't HAVE to be implemented using NIO. But the 
pattern lends itself to using NIO, as it is event based.

>> 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?

Right, if the class is not available on the classpath, that would be a 
problem. One approach to addressing this is to use a custom classloader 
that looks for classes in jars that are placed in a special directory, 
for example. Then, all you would need to do is place the thick client 
application jars in that directory, and the classloader would find them 
there.

Not sure what the Burp extension did in this case, but the above is how 
I would approach it.

Rogan