3 ms·

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.

homakov 13y ago
i don't downvote, but referer never been a good protection. never
skyraider 13y 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 13y ago
You 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 ago
Who said this attack was coming from a browser? Never. Trust. User. Input.
- skyraider 13y ago
  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.
  - pdeuchler 13y ago
    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).
    - skyraider 13y ago
      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.

homakov 13y ago

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

skyraider 13y 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 13y ago

You 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 ago

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

skyraider 13y ago
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.
- pdeuchler 13y ago
  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).
  - skyraider 13y ago
    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.