Hmmmm, while I'm a big fan of the OP I don't think this is really a security flaw.
I'm praying to God that Facebook doesn't use CSRF as their only stop gap measure against malicious POST requests, and if that were the case then OP might have a point, but in my opinion CSRF is more of a buffer that helps prevent scale-able automated form submissions.
If I understand it correctly, OP demonstrates that a simple curl can get a CSRF token that can then be used to send malicious POST requests, but isn't that almost the same thing as loading up the webpage and typing in the data in the form yourself? I feel like you're still throttling the requests, as HTTP requests before every POST does not scale. This could also be very easily detected server side and easily blocked.
3. ExampleBank.com observes that request doesn't contain a correct token parameter, so rejects the request.
Evil.com could not fetch the token themselves by curl or any other means: the token is tied to the user's account, so Evil.com would have to send the request on the client-side in order to send the request with the user's cookies. And, since Evil.com is not ExampleBank.com, the request would successfully send but cross-domain security policy would prevent Evil.com from reading the response. Therefore, only ExampleBank.com can access the token, so only ExampleBank.com can send authorized requests.
>However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check.
ridiculous, say forging again, i double dare you.
how you ninjas going to do that? flash 10 was released 2008.
thanks for down voting, single mind hn as usual.
Thanks for pointing this out. A lot of people here don't seem to realize that exploiting a CSRF vulnerability involves tricking the victim's browser into doing something.
You cannot both a) forge the Referer header and b) trick the victim's browser into submitting a request - at the same time.
It's true that the REFERER header isn't always included in requests, BUT when it is included, you can consider the request cookies you receive plus the REFERER header accurate when taken together, barring a browser vulnerability. If there is no browser vulnerability, the attacker doesn't get to mess with the REFERER header on the victim's browser.
Note: It is NOT safe to trust an empty REFERER header.
If a CSRF attack is not coming from a browser, how are you going to get the victim's session cookies? If you do get them, it's not called CSRF anymore.
What's stopping an attacker from harvesting session cookies, and then using them in a separate attack? I'm not that familiar with it, but possibly phantom.js hooked up to an exploit tool could work as well?
I'm not saying referrer checking is useless, but once again, you never trust user input. Ever. If you follow that rule you're decreasing attack vectors to essentially social engineering, brute force, and complex technological exploits using buffer overflows and the like (which I guess is still kind of a side effect of trusting user input).
Well, a CSRF attack doesn't involve reading cookies. I believe you'd need an XSS vulnerability in order to do that. (Or, if the site isn't using SSL, just sniff the network traffic.) CSRF just transmits the legitimate cookies to the server - but with a request the victim probably didn't want to actually send. At no point are the victim's cookies able to be harvested.
You could indeed possibly forge a request after harvesting session cookies - but that isn't CSRF. It's either XSS or traffic snooping.
One way to cut down the (time) window of opportunity for an attack is to have the server generate new session tokens, and store them in the cookie, on each request, but require a valid token in order for a new token to be generated. If you have an XSS vulnerability, this is not an adequate solution, as it requires the victim to submit another request between the time the attacker steals the cookie and the time the attacker submit the cookie to the server.
So basically, use SSL and be really careful about XSS. You can trust the REFERER header and session cookies together if and only if they are both present. "Never trust user input that you have to escape or that will be rendered to the browser" is very reasonable though.
That's incorrect in this context, which is trying to get a victim to use their own browser to submit a request that uses cookies on said browser for authentication (CSRF). Please take a look at the following link:
"Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack."
I'm praying to God that Facebook doesn't use CSRF as their only stop gap measure against malicious POST requests, and if that were the case then OP might have a point, but in my opinion CSRF is more of a buffer that helps prevent scale-able automated form submissions.
If I understand it correctly, OP demonstrates that a simple curl can get a CSRF token that can then be used to send malicious POST requests, but isn't that almost the same thing as loading up the webpage and typing in the data in the form yourself? I feel like you're still throttling the requests, as HTTP requests before every POST does not scale. This could also be very easily detected server side and easily blocked.
Am I understanding this correctly?