user1283002
user1283002

Reputation: 501

How to listen on browser requests (proxy, addon...)?

I wanted to know what is the best way to write an agent on Win platform that will be able to monitor browser's communication.

scenario: monitor the user access to predefined url on Chrome, FireFox and IE. On each hit I send the stats to a server with some data (page title).

The ways I found so far are proxy and browser addons. Each has it's own advantages and disadvantages. The main disadvantage of the proxy way is handling of HTTPS communication. The addon disadvantage is the installation (need to install on every browser) and cross-browser support.

Is there another way? some service I can write with .net that will automatically hook on a browser when it is started?

Thanks you.

Upvotes: 0

Views: 1487

Answers (1)

Andras Zoltan
Andras Zoltan

Reputation: 42343

You do have only two choices - an http proxy, or to write a plugin for every browser. That plugin could just forward data via network to a central service, leaving you with the challenge of coming up with a common set of data that all browsers can provide, plus learning all the plugin models.

In my opinion, though, the only real option is an HTTP(s) proxy because otherwise you have to keep updating your plugins every time browsers change, or deal with the fact that new browsers can come along and be used.

Certainly you won't find a 'user is browsing a url in some browser' event in the OS - all it knows is that a socket connection has been opened on some local port to a remote server's port 80/443 (or whatever).

So I strongly suggest building on top of the excellent work that's behind Fiddler and use the Fiddler Core.

http://www.telerik.com/fiddler/fiddlercore

For https you have to decrypt and re-encrypt with a different certificate. The information that you need is just not available without actually unpacking the request. Fiddler achieves this by opening it's own SSL tunnel to the target server on the client's behalf, whilst acting as an SSL server to the client under a different certificate. So long as the certificate that it uses is fully trusted by the client, no problems occur.

That said, it means that the user cannot personally verify the identify of the target site - therefore your system would have to assume worst case scenario for any invalid SSL certificates and block the connection.

Upvotes: 1

Related Questions