Pentesting serial object (SO) applications like smartclients :: IN CONCEPT

Lets address the problem of serial object communication in web applications using the sniff and edit method. The problem with using a servlet to cast objects is that the request can’t be kept in motion for server and client to interpret.

One look at the request header:

Content-Type: application/octet-stream

This stream data must be cast to an object to retrieve and edit data.

To capture the request and response there is the old /etc/hosts and reverse proxy trick, to fool the smart client to point to a local running reverse proxy. This will still not interpret the serial object from the client. We need some bean shell code to offset this odd.

The solution is to modify web scarab to function as an object decoder and reverse proxy.

So creating a new transparent layer with reverse proxy setup is a solution to testing SO objects.

Let’s see the server side code to interpret this octet-stream which will cast the stream to a class object at server side. I am writing java code here, but the idea pretty much remains the same for the beanshell. I can’t disclose any legacy/proprietary information in the code.

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

PrintWriter pw = response.getWriter();

try{printRequest(request, pw);}

catch (Exception e) {pw.write("\nCaught Exception: " + e);}

pw.flush();}

public void printRequest(HttpServletRequest req, PrintWriter pw)

{ObjectInputStream objInStream = new ObjectInputStream(servletinputstream);

RequestObject o1= (RequestObject)objInStream.readObject();

...some data processing with serial array type objects...

pw.write("\n**********Request data********:\n");

pw.write("\no1.toString="+o1.toString());}

One will have to fetch the request and response object class from the jars/libs downloaded in the temporary folders by the application (use any process monitor to fetch the library/jar names used by the process). The process can be replicated with HTTPS communication.

Some Basic assumptions for smart client applications:

1. We talk of smart clients where proxy can’t be configured.

2. Smart Client applications work using http wrapper.

3. The http wrapper contains binary application data. This application data is contains class objects.

4. Communication jars downloaded at client side by smart client contains class instance to map these objects.

5. Some smart clients use open SOAP (XML based) in http wrapper for communication.

6. Binary data can be cast in class definition and edited by hex editor.