W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

RE: CSRF: alternative solutions

From: Mike Wilson <mikewse@hotmail.com>
Date: Mon, 8 Jun 2009 17:50:48 +0200
Message-ID: <BAY116-DAV550F784A8CCA2CFF10B1DA4470@phx.gbl>
To: "'Giovanni Campagna'" <scampa.giovanni@gmail.com>, <public-webapps@w3.org>
Message-ID: <01a201c9e850$e49fb7b0$0a01a8c0@mikedeskxp>
Giovanni Campagna wrote:
> 1) user visites http://www.mybank.com/login
> 2) the server sends a cookie, call it MyBankSID, with the 
> login information
> 3) user visites http://www.dangerous.com/ within the 
> expiration time of cookie
> 4) the user clickes a link (or sends a form) to
> http://www.mybank.com/pay?to=hacker
> 5) the browser sends MyBankSID cookie, which grants access to user's
> bank account
> 6) money goes from the user to the attacker

There actually is no need of user action in (4) to be hit by the
security leak. If the protected URL can be called with GET then
it's enough for www.dangerous.com to include f ex an
  <img src="http://www.mybank.com/pay?to=hacker">
and the victim's browser will happily send the request together 
with the secret cookie at page load time.
If POST is required then it can be done by script and a hidden
iframe, also at page load time.

Best regards
Mike Wilson
Received on Monday, 8 June 2009 15:51:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT