3 ms·
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 mea
by pdeuchler 13y ago
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.
Am I understanding this correctly?
- matchu 13y agoCross-site request forgery prevention is all about cross-domain browser security policy. 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 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 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.
- homakov 13y agoHey, thanks for warm words. This post is not about vulns, it's about a tool I created to find vulns. :)
- pdeuchler 13y agoAhhhh, gotchya. So essentially an automated tool to find who's not doing a little extra server side validation? edit: Might I suggest you add a bitcoin wallet for donations as well?
- homakov 13y agonot automated, but really convenient and simple (for me at least) I don't have a wallet yet (