- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Mon, 8 Jun 2009 18:23:28 +0200
- 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 UTC