OWASP ZAP and Web Sockets

Mon 15 July 13

With the slow uptake of HTML5, web sockets are going to start being seen in more and more applications so I figured I'd better learn how to test them before being put in front of them on a client test and having to learn as I went along.

I figured the best way to do this was to build a very simple application then throw in a proxy and see what happened. Unfortunately my proxy of choice, Burp Suite, currently doesn't handle web sockets so I had to look for one that did. The only one, and this is their claim, that does in the OWASP Zed Attack Proxy, or ZAP for short. I'd been meaning to learn how to use it for a while so this seemed like the perfect opportunity. If anything in here is wrong, please get in touch and I'll fix it, I'm learning as I go along so may well be doing the odd thing wrong however it does all seem to work.

I started by writing a small web socket based app which I called SocketToMe which has a few basic services, chat, a number guess game and a couple of other features. I figured I'd start with interception then have a look at fuzzing.

Basic interception is really simple, ZAP listens on port 8080 by default so you just point your browser at it like you would any other proxy. If you need to change the port number for any reason it is hidden away a little bit, from the Tools menu select options then "Local proxy" in the left hand menu.

I started using the app and ZAP picked up both the HTTP and the web socket traffic straight away. To see the web socket traffic simply go to the WebSockets tab. The following screenshot shows three messages, the arrows show the direction of the message, to or from the client.

ZAP showing web socket
interception

The equivalent of Burp's repeater is Resend, to do this right click on a message and select "Resend..." . You'll be given a new window where you can modify the message, change the direction (to server or client) and the Opcode (don't know what this is).

Resending a message

If you want to intercept traffic and modify it before it hits either the client or the server then you set a break point. Right click on a message and chose "Break..." this will show a message box where you can specify which direction, channel and opcode you want to break on. You can also specify a pattern in the payload to watch for when breaking, this is useful to only stop on specific messages. The pattern takes regular expressions so in the following screenshot I've got it breaking when the client sends the server (outgoing) any message which contains a 3 followed by another number (3[0-9]).

Setting a break point

bottom window where you will see a list of all the ones that have been defined. You can edit and delete them with a right mouse click or temporarily disable them with the checkbox.

List of current break points

To edit, or remove, break points, go to the "Break Point" tab in the bottom window where you will see a list of all the ones that have been defined. You can edit and delete them with a right mouse click or temporarily disable them with the checkbox.

List of current break points

The last bit I'm going to cover is fuzzing but as this is already fairly long I'm going to push this to part two, Fuzzing Web Sockets With ZAP.

Thanks BruCON

The time to create this project was kindly sponsored by the BruCON 5x5 award.