CSRF Tool
homakov.blogspot.ru
homakov.blogspot.ru
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?
A CSRF attack looks something like this:
1. Victim visits Evil.com.
2. Evil.com auto-submits a form to http://www.ExampleBank.com/transfer-money with parameters {"recipient": "attacker's account ID", "amount": 1000000}
3. If ExampleBank.com fails to prevent CSRF attacks, the user will unwittingly transfer $1 million to the attacker.
The technique described in the article would successfully block this attack:
1. Victim visits Evil.com.
2. Evil.com auto-submits a form to http://www.ExampleBank.com/transfer-money with parameters {"recipient": "attacker's account ID", "amount": 1000000}
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.
edit: Might I suggest you add a bitcoin wallet for donations as well?
I don't have a wallet yet (
Referer: not reliable, proxies omit it Origin: not supported yet Additional header: could be tricked with Flash vuln
https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...
"Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack."
(https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...)
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.
Never. Trust. User. Input.
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).
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.