4 ms·
CSRF Tool
- alexchamberlain 13y agoYour mitigation is wrong. You need a one way function around the cookie, otherwise that can be forged too.
- tptacek 13y agoIf a blind attacker can't predict the token, and the token is reliably checked on form submission, it mitigates CSRF.
- homakov 13y agofurther more: this is one and the only proper protection. Referer: not reliable, proxies omit it Origin: not supported yet Additional header: could be tricked with Flash vuln
- stopcyring 13y agochecking referer will work 99% and without cluttering your urls.
- jere 13y ago>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. https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Checking_The_Referer_Header https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...
- diffsir 13y agoNot to mention one can leverage flash to spoof headers or the odd IE bug that splits headers using \t
- stesch 13y agoPlease stop relying on the Referer header. It can be forged and is often enough removed completely for privacy reasons.
- trxblazr 13y agoabsolutely not. Just forge the referrer header.
- skyraider 13y agoThat'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." (https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Checking_The_Referer_Header https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...)
- stopcyring 13y agoridiculous, 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.
- homakov 13y agoi don't downvote, but referer never been a good protection. never
- skyraider 13y agoThanks 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.
- ljd 13y agoYou can forge the referrer by putting it in the header of an HTTP request. It's a rather simple procedure.
- deleted 13y ago[deleted]
- pdeuchler 13y agoWho said this attack was coming from a browser? Never. Trust. User. Input.
- skyraider 13y agoIf 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.
- homakov 13y agoNoooooooo
- hawkharris 13y agoExtra points for incorporating a rap video into a technical security blog post.
- homakov 13y agoDat's how we roll, homie
- deleted 13y ago[deleted]
- bvdbijl 13y agoMaybe you should do something other than alert() the CSRF exploit, I can't copy it under Windows
- homakov 13y agohmm, maybe a popup with text area. feel free to Pull request
- pdeuchler 13y agoHmmmm, 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. :)