101–110 of 256 posts
Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).
It didn't log me out. Must be down to Chrome Adblock, or Facebook Disconnect.
[ repost from below ] I just read on CSRF and its mitigation with Synchronized Tokens on [1] and there's one thing I don't seem to understand. What does prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/move-funds tha…
Because a script (I assume you're referring to JavaScript) can't fill in a form on or read the contents of a third-party website. That's a violation of the same-origin policy. CSRF tokens are a well-understood solution to this issue. In order to submit a valid request, you must include what is essentially a secret token that is on the page (although the secret token can just be your session ID). For an attacker to ge…
Now, let's say my script is not loading bank's page into an iframe, but rather fetches it with an ajax call. Wouldn't that page (again) include a valid CSRF token? Or is this mitigated by checking a referrer on the bank's side?
Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).
It didn't log me out. Must be down to Chrome Adblock, or Facebook Disconnect.
If Google required a POST to log out (as it should be, since logging someone out is changing the session state and therefore not a "safe" GET-able request[1]), we could fall back to CORS as protection which removes the need for a CSRF token. Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would r…
I'm not quite sure what you're trying to say here. But you can make cross-domain POST requests in two ways, both involving JavaScript:
1. Create an HTML form, use JavaScript to submit it.
2. Use XMLHttpRequest to make a cross-domain POST.
Earlier quoted context omitted.
Yeah, there are plenty of reasons to do what you're doing that seem fair to me. But at the same time, through no fault of yours, your requests are indistinguishable from potentially malicious ones. The whole thing is a mess, effectively a band-aid on top of deeper issues with HTTP's statelessness. Also: that's a good link. Thanks.
If I'm blocking cookies/referer by default then the onus is upon me to enable them for sites that require them for stuff like this. I wouldn't worry about users who have this issue. Maybe customize django's CSRF failure page to say they need to enable both to use your service and call it a day.
In practice, lots of my potential users don't even understand that their AdBlock/whatever extensions are mucking about with Cookies in ways that break things. It's a tough sell to tell someone who is thinking about trying your service: "sorry, I don't work with your browser the way it is" when so much of the rest of the world is either HTTP, not HTTPS, or simply has decided to punt on CSRF or be much more selective about it. It looks to them like _I'm_ the one that's broken.
Argh. It's no-win.
For those who didn't see the recent kerfuffle: This guy recently found and demonstrated a major Rails exploit on github. He seems to know a thing or two about security exploits.
Clarification: he didn't recently find the exploit. He's been making noises about it for a very long time and being ignored, so he took the (dubious, to some) step of using the exploit publicly and loudly, to draw attention to the problem.
It's like the difference between the class of buffer overflow exploits and the buffer overflow exploit in a particular piece of software.
There's a significant difference between the two.
I'm having a little trouble parsing this post. Is he saying he's discovered a variant of CSRF that cannot be stopped by using the Synchronizer Token Pattern? Or has he found something that a lot of site's protection patterns don't follow?
You seem to be familiar with the subject. I just read through CSRF and Token stuff on [1] and there's one thing I don't seem to understand. What would prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/operations/move-…
If Google required a POST to log out (as it should be, since logging someone out is changing the session state and therefore not a "safe" GET-able request[1]), we could fall back to CORS as protection which removes the need for a CSRF token. Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would r…
Earlier quoted context omitted.
Because a script (I assume you're referring to JavaScript) can't fill in a form on or read the contents of a third-party website. That's a violation of the same-origin policy. CSRF tokens are a well-understood solution to this issue. In order to submit a valid request, you must include what is essentially a secret token that is on the page (although the secret token can just be your session ID). For an attacker to ge…
Right, the same-origin policy, thanks. Just found it after a minute of jsfiddling. Now, let's say my script is not loading bank's page into an iframe, but rather fetches it with an ajax call. Wouldn't that page (again) include a valid CSRF token? Or is this mitigated by checking a referrer on the bank's side?