Re: penproxy accessing javascript?

[Rogan Dawes <discard () dawes za net>]

Mads Rasmussen wrote:
> I have come across several webpages where some calculations were done in 
> javascript, like cryptography or routines to handle the virtual 
> keyboard, broadly used in internet banking here in Brazil (if someone 
> wants me to explain the idea I will do)
>
> When doing analysis it crossed my mind to look for some kind of penproxy 
> with the capability of evaluating the javascript code.
> Imagine a trojan installing a local proxy for the browser and then 
> evaluating the javascripts it sees for a specific site, if it does 
> crypto it can see the key, if it handles the virtual keyboard it will 
> see the passwords entered on the keyboard.
>
> I had another look at webscarab, what is the java bean stuff about? it 
> doesn't seem to do what I want though
>
> Anyone knows of one?
>
> Regards,
>
> Mads

Disclaimer: These responses are from the author of WebScarab.

The difficulty with having a proxy executing Javascript is in deciding 
when to fetch scripted pages, and when not to, as well as maintaining an 
exact copy of the state of the browser across "javascript:back" and 
other manipulations. One critical problem to solve for crypto in 
particular, is getting access to any random numbers that the browser 
uses as the basis for its key exchange.

This is not an easy thing to solve (at least, I don't think it is. If 
someone has an idea how to do it, please let me know!)

The beanshell support in WebScarab is intended to allow repetitive 
execution of some script against the request and the response (to the 
request prior to fetching from the server, and to the response prior to 
sending to the browser.) The objective here is to automate tedious 
things that it is not easy to make a gui for (e.g. change this 
particular header in this particular way, but only when the URL is that, 
or some other query parameter is present).

It is currently being extended to allow the script to maintain state 
across conversations (a request and matching response), which can be 
useful. It MAY then be possible to use Rhino to perform parallel 
execution/processing of the pages, although it would still not solve the 
question of the random numbers raised above.

My personal preference would be to script a modification to the 
javascript itself that is executed in the browser, to expose the keys to 
you in some appropriate way. For example, when we receive a request for 
"crypto.js", rather than fetching it from the server, fetch a modified 
version from the filesystem, and return it to the browser.

The modified version could possibly result in the key being sent to the 
proxy as an additional request parameter, with the proxy removing it 
before sending it on to the upstream server.

That would be *my* approach in this instance.

Regards,

Rogan
--
Rogan Dawes

*ALL* messages to discard () dawes za net will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"