Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSRF Tool

homakov.blogspot.ru

Post reply on HN
Print view View original

21–30 of 30 posts

Re: CSRF Tool

#21

Post by pdeuchler »

homakov wrote: post #14
pdeuchler wrote: post #10

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…

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

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?

Re: CSRF Tool

#22

Post by skyraider »

stopcyring wrote: post #13
stopcyring wrote: post #4

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

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.

Re: CSRF Tool

#23

Post by skyraider »

trxblazr wrote: post #11
stopcyring wrote: post #4

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

absolutely not. Just forge the referrer header.

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

Re: CSRF Tool

#24

Post by ljd »

stopcyring wrote: post #13
stopcyring wrote: post #4

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

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.

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

Re: CSRF Tool

#25

Post by [deleted] »

ljd wrote: post #24
stopcyring wrote: post #13

Earlier quoted context omitted.

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.

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

[deleted]

Re: CSRF Tool

#26

Post by pdeuchler »

stopcyring wrote: post #13
stopcyring wrote: post #4

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

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.

Who said this attack was coming from a browser?

Never. Trust. User. Input.

Re: CSRF Tool

#27

Post by skyraider »

pdeuchler wrote: post #26
stopcyring wrote: post #13

Earlier quoted context omitted.

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.

Who said this attack was coming from a browser? Never. Trust. User. Input.

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.

Re: CSRF Tool

#28

Post by homakov »

pdeuchler wrote: post #21
homakov wrote: post #14

Earlier quoted context omitted.

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

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?

not automated, but really convenient and simple (for me at least)

I don't have a wallet yet (

Re: CSRF Tool

#29

Post by pdeuchler »

skyraider wrote: post #27
pdeuchler wrote: post #26

Earlier quoted context omitted.

Who said this attack was coming from a browser? Never. Trust. User. Input.

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

Re: CSRF Tool

#30

Post by skyraider »

pdeuchler wrote: post #29
skyraider wrote: post #27

Earlier quoted context omitted.

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 t…

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.

Post reply on HN