Re: "ClientSideTrojan" bug

[mfrancis () PLUS NET UK (Matthew J.Francis)]

Hi,

The irritation of this attack seems mainly to be that the attacker needs
know no secret about the victim, and so the same attack will work equally
for anyone authenticated to a particular service.

Given that it's common to issue some sort of session ID to a user upon login
(separate from, for example, a persistent identification cookie), and that this
won't easily be available to an attacker, a quick and obvious way to kick this
problem in the nads would seem to be to embed the user's session ID in any form
resulting in a state change in their data (configuration, purchase, whatever).
Then, compare that supplied ID against the authenticated session ID before
actioning a GET/POST request.

Randomly submitting a dummy form then isn't enough, and the attack should be
defanged for the cases:

  1. Redirect to a GET action
  2. Forced POST submission by Javascript
  3. Evil innocent-looking form

But not of course in the general case for

  4. Browser is vulnerable to cross-site scripting

If random Javascript can find out what's going on in another window you're
just as doomed as ever.

(Bonus points for warning users on login that their browser is vulnerable
based on their user-agent string - is there a list of historically vulnerable
browsers anywhere?)

-Matt.