CSRF Tool

http://homakov.blogspot.ru/2013/05/csrf-tool.html

by homakov • 13 years ago

64 26 13 years ago

homakov.blogspot.ru

alexchamberlain• 13 years ago

Your mitigation is wrong. You need a one way function around the cookie, otherwise that can be forged too.

tptacek• 13 years ago

If a blind attacker can't predict the token, and the token is reliably checked on form submission, it mitigates CSRF.

homakov7• 13 years ago

further 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

stopcyring2• 13 years ago

checking referer will work 99% and without cluttering your urls.

jere• 13 years 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...

stesch• 13 years ago

Please stop relying on the Referer header. It can be forged and is often enough removed completely for privacy reasons.

trxblazr• 13 years ago

absolutely not. Just forge the referrer header.

skyraider4• 13 years ago

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."

(https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...)

stopcyring2• 13 years ago

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.

homakov7• 13 years ago

i don't downvote, but referer never been a good protection. never

skyraider4• 13 years ago

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.

ljd• 13 years ago

You can forge the referrer by putting it in the header of an HTTP request. It's a rather simple procedure.

pdeuchler4• 13 years ago

Who said this attack was coming from a browser?

Never. Trust. User. Input.

homakov7• 13 years ago

Noooooooo

hawkharris• 13 years ago

Extra points for incorporating a rap video into a technical security blog post.

homakov7• 13 years ago

Dat's how we roll, homie

bvdbijl• 13 years ago

Maybe you should do something other than alert() the CSRF exploit, I can't copy it under Windows

homakov7• 13 years ago

hmm, maybe a popup with text area. feel free to Pull request

pdeuchler4• 13 years 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• 13 years ago

Cross-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 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.

homakov7• 13 years ago

Hey, thanks for warm words. This post is not about vulns, it's about a tool I created to find vulns. :)

pdeuchler4• 13 years ago

Ahhhh, 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?

CSRF Tool

Related Stories