91–100 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).
Earlier quoted context omitted.
Yeah this is something I run into often as I don't accept cookies from sites by default and don't send Referer header (both are required for django's CSRF middleware if over https). This is a good read if you are interested in the rational behind these decisions -> https://code.djangoproject.com/wiki/CsrfProtection As far as a solution for your users, I'd just let them know that you require cookies to login (obviousl…
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.
I wonder what will happen to websites which use cross-domain post requests to log in securely, e.g. http://example.com submitting the login form to https://secure.example.com
CSRF is a bit of a pain to work around but how much of a problem is it in the wild? Most sites where this could do real damage (and have real gains for the attacker), banks etc are going to be well protected. You could use it to comment spam a blog but that's going to be a crapshoot. Guessing which blog people are logged into etc, you would need very targeted attacks. Sure , signing out of google is annoying but if y…
>Most sites where this could do real damage (and have real gains for the attacker), banks etc are going to be well protected. You think so. In "the wild" even serious systems are vulnerable #OpApril1
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-…
[ 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…
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 get that token, they would need to be able to do at least one of the following:
A. Guess it, by having you make multiple requests. (so you make the token long enough that it's infeasible to guess)
B. Be able to read it by intercepting the HTTP response or reading it in some way, in which case you have much larger security issues.
C. Be able to read the token in the HTTP request that the browser makes. Again, if an attacker can do this, your session is already compromised.
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?
he discovered that you can log out from google via a GET request (surprise!)
I don't see a way browsers could effectively enable CSRF protections. How is it supposed to know you don't want to request that page as an image? What about sites linking to images on other domains? CDNs would be blocked, because how is Chrome supposed to know you actually wanted to load the image from fbcdn.net or s3.amazonaws.com?
It's not up to browsers to prevent this. Just like how you can't rely on client side data validation you must always take proper precautions on the server. Browsers taking additional precautions to prevent this would be nice but it's not the whole solution and never will be.
Edit: If you're going to downvote this please leave a reply stating why. I don't understand an opposing point of view unless you use 3rd party cookies to track people across domains.
Still, using buttons for logging out, consistently across the entire web, would take some effort. CSRF tokens are probably less intrusive.
[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...
[ 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…