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

Re: CSRF: alternative solutions

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Mon, 8 Jun 2009 18:23:28 +0200
Message-ID: <65307430906080923t7061c2fck88934577660bff4b@mail.gmail.com>
To: Mike Wilson <mikewse@hotmail.com>
Cc: public-webapps@w3.org
2009/6/8 Mike Wilson <mikewse@hotmail.com>:
> 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.

1) Sharing of resources across origines needs to be regulated despite
CSRF: that's the reason for CORS
2) GET requests should be safe. If they're not, the website is seriously flawed.

> If POST is required then it can be done by script and a hidden
> iframe, also at page load time.

When submitting the hidden iframe, the user could be awared that a
POST is (automatically) being done to a different website, and stop
such action.

> Best regards
> Mike Wilson
>

Giovanni
Received on Monday, 8 June 2009 16:24:01 GMT

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