Comments on: Preventing CSRF http://www.gnucitizen.org/blog/preventing-csrf/ Information Security Think Tank Thu, 11 Mar 2010 22:49:16 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: sibidiba http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-128104 sibidiba Sat, 16 Jan 2010 03:38:05 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-128104 A tipical CSRF attack scenario: You receive an e-mail or a web page with a link on it. You click the link. The link is for example: http://bank.example.com/transfer?amount=1000&to=12345 or an equivalent POST request. You are logged in with the same browser on bank.example.com . Therefore the site will think the request *is* coming on your behalf. Wont be the SESSIONDID still be there? Isn't this the reason while the request would already reach this point of code, assuming you are logged in? The presence of your session in the browser is the core of this attack vector. The session is identified by the SESSIONID cookie, isn't it? Then your solution wouldn't work. A tipical CSRF attack scenario: You receive an e-mail or a web page with a link on it. You click the link.

The link is for example: http://bank.example.com/transf.....p;to=12345
or an equivalent POST request.

You are logged in with the same browser on bank.example.com . Therefore the site will think the request *is* coming on your behalf. Wont be the SESSIONDID still be there? Isn’t this the reason while the request would already reach this point of code, assuming you are logged in? The presence of your session in the browser is the core of this attack vector. The session is identified by the SESSIONID cookie, isn’t it? Then your solution wouldn’t work.

]]> By: Inferno http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-127633 Inferno Sun, 19 Jul 2009 07:30:20 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-127633 Hi pdp, Just to add my input to your insightful post, i got an idea of a pure client side attack to locate csrf tokens using jeremiah's css history hack. some readers commented on using a hash of session id. if this hash is short length and is part of url, then this attack is feasible (even when links to external sites=0). more details here - http://securethoughts.com/2009/07/hacking-csrf-tokens-using-css-history-hack/ Hi pdp,

Just to add my input to your insightful post, i got an idea of a pure client side attack to locate csrf tokens using jeremiah’s css history hack. some readers commented on using a hash of session id. if this hash is short length and is part of url, then this attack is feasible (even when links to external sites=0). more details here – http://securethoughts.com/2009.....tory-hack/

]]> By: Preventing CSRF, the Right Way - KeepItLocked.net http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-124092 Preventing CSRF, the Right Way - KeepItLocked.net Fri, 17 Oct 2008 22:01:00 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-124092 [...] type="Submit" value="Click Me"/> </form> This type of solution is suggested by some reputable sources in application security. In some cases, the CSRF token is the session ID. There are [...] [...] type=”Submit” value=”Click Me”/> </form> This type of solution is suggested by some reputable sources in application security. In some cases, the CSRF token is the session ID. There are [...]

]]> By: r3ck0rd http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-121039 r3ck0rd Wed, 07 May 2008 08:51:31 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-121039 ^ a newbie? well yes it could be, easily using PHP :) ^ a newbie?
well yes it could be, easily using PHP :)

]]> By: Accounts Security Part III | Th0R's Blog http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-119426 Accounts Security Part III | Th0R's Blog Tue, 22 Apr 2008 10:35:31 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-119426 [...] CSRF Attack: for users and WDev&P Lists of links that may help you preventing CSRF: - http://www.gnucitizen.org/blog/preventing-csrf/ - http://websecurity.ro/blog/2008/03/28/wordpress-233-probably-a-0day-exploit/ - [...] [...] CSRF Attack: for users and WDev&P Lists of links that may help you preventing CSRF: – http://www.gnucitizen.org/blog/preventing-csrf/ – http://websecurity.ro/blog/200.....y-exploit/ – [...]

]]> By: Accounts Security Part III | r3ck0rd's Blog http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-118623 Accounts Security Part III | r3ck0rd's Blog Fri, 11 Apr 2008 13:24:18 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-118623 [...] CSRF Attack: for users and WDev&P Lists of links that may help you preventing CSRF: - http://www.gnucitizen.org/blog/preventing-csrf/ - http://websecurity.ro/blog/2008/03/28/wordpress-233-probably-a-0day-exploit/ - [...] [...] CSRF Attack: for users and WDev&P Lists of links that may help you preventing CSRF: – http://www.gnucitizen.org/blog/preventing-csrf/ – http://websecurity.ro/blog/200.....y-exploit/ – [...]

]]> By: Preventing CSRF efficiently » Inking's Security Blog http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-116811 Preventing CSRF efficiently » Inking's Security Blog Tue, 18 Mar 2008 17:01:20 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-116811 [...] forgeries and how to prevent them, however this time slightly different and not only dealing with approaches that have already been discussed numerous times and are likely to fail under certain well known circumstances. It's actually difficult to start on [...] [...] forgeries and how to prevent them, however this time slightly different and not only dealing with approaches that have already been discussed numerous times and are likely to fail under certain well known circumstances. It’s actually difficult to start on [...]

]]> By: Zoiz http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-103503 Zoiz Fri, 25 Jan 2008 13:25:23 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-103503 Newbie here. Can I prevent CSRF by matching the referrer URL with my site URL? Newbie here. Can I prevent CSRF by matching the referrer URL with my site URL?

]]> By: pdp http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-15660 pdp Mon, 23 Apr 2007 08:46:34 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-15660 Scott, good summary my man. Scott,

good summary my man.

]]> By: Scott Parsons http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-15098 Scott Parsons Fri, 20 Apr 2007 18:42:02 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-15098 Newbie here, but have been thinking and discussing CSRF with some other folks. I'm feeling pretty large that I had come up with the same approach as PDP a couple weeks ago. While it sessionID <strong>should</strong> be safe to use, it would seem prudent to use a secure hash of it rather than the sessionID itself. Provided there is sufficient entropy in the session Id and output bits in the hash, it should be rainbow-table proof. The advantage is that there is no secret to keep, and it can either be calculated on the server or on the client-side. This also allows it to be valiated in multiple places without the need to do secret key management, which might be required for an HMAC approach. Newbie here, but have been thinking and discussing CSRF with some other folks. I’m feeling pretty large that I had come up with the same approach as PDP a couple weeks ago. While it sessionID should be safe to use, it would seem prudent to use a secure hash of it rather than the sessionID itself. Provided there is sufficient entropy in the session Id and output bits in the hash, it should be rainbow-table proof. The advantage is that there is no secret to keep, and it can either be calculated on the server or on the client-side. This also allows it to be valiated in multiple places without the need to do secret key management, which might be required for an HMAC approach.

]]> By: pdp http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-14258 pdp Fri, 13 Apr 2007 07:05:54 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-14258 naka, yes it will work. the problem is how we are going to prevent CSRF without introducing too mush stuff into the system. but yes, this works. naka, yes it will work. the problem is how we are going to prevent CSRF without introducing too mush stuff into the system. but yes, this works.

]]> By: naka http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-14252 naka Fri, 13 Apr 2007 06:14:41 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-14252 How about using a hashed JSESSIONID instead of raw one? I think that it is better than the way you suggested. How about using a hashed JSESSIONID instead of raw one?
I think that it is better than the way you suggested.

]]> By: pdp http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-13143 pdp Sat, 07 Apr 2007 06:18:41 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-13143 Kyle, It all depends. We cannot say whether your application is secure or not. Rethink all technologies that you are using and make sure that they are applied appropriately. Kyle,

It all depends. We cannot say whether your application is secure or not. Rethink all technologies that you are using and make sure that they are applied appropriately.

]]> By: Kyle http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-13104 Kyle Sat, 07 Apr 2007 01:01:31 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-13104 In my admin section, the forms are submitted over xmlhttprequest. So instead of using javascript to rewrite the dom and add hidden inputs, couldn't I just modify my xmlhttprequest wrapper to add a custom header with a unique id from the cookie? The header is then checked in the back end. This would only require 1 line of extra code client side and is faster than rewriting the dom. It also means that if you have different panels of the admin section open in separate tabs then they all have the most recent id whenever you eventually submit them (which a dom rewrite onload may not and even though a dom rewrite onsubmit would it's less efficient). I regularly regenerate the session id so this is an issue for me. If the user has javascript turned off, the js is incompatible with the browser or the js is just plain borked then the id will not be sent because there's no fall back, but that isn't a problem here since the admin section is private and for me only. Does this method open any new holes that I haven't noticed? In my admin section, the forms are submitted over xmlhttprequest. So instead of using javascript to rewrite the dom and add hidden inputs, couldn’t I just modify my xmlhttprequest wrapper to add a custom header with a unique id from the cookie? The header is then checked in the back end.

This would only require 1 line of extra code client side and is faster than rewriting the dom. It also means that if you have different panels of the admin section open in separate tabs then they all have the most recent id whenever you eventually submit them (which a dom rewrite onload may not and even though a dom rewrite onsubmit would it’s less efficient). I regularly regenerate the session id so this is an issue for me.

If the user has javascript turned off, the js is incompatible with the browser or the js is just plain borked then the id will not be sent because there’s no fall back, but that isn’t a problem here since the admin section is private and for me only.

Does this method open any new holes that I haven’t noticed?

]]> By: wrc http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-12294 wrc Mon, 02 Apr 2007 15:29:02 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-12294 An attack using XMLHTTP to make the requests through the victim's browser against the desired site will only need an additional intermediate step. Soley protecting POSTs won't help. An attack using XMLHTTP to make the requests through the victim’s browser against the desired site will only need an additional intermediate step. Soley protecting POSTs won’t help.

]]> By: beaule http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-12036 beaule Mon, 02 Apr 2007 07:18:33 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-12036 to pdp @ "XSS is a lot more dangerous then simple CSRF, which means that if you can get XSS then why the hell you would like to do CSRF" -- why? it's very very simple, if a transfer application is CSRFable and XSSable, i will do an CSRF to retrieve money from the user to my account. So even if my application is XSSable i will my transfer application totaly safe against CSRF... That's why i think that a CSRF protection must be safe against XSS attack! to pdp @ “XSS is a lot more dangerous then simple CSRF, which means that if you can get XSS then why the hell you would like to do CSRF”
–
why? it’s very very simple, if a transfer application is CSRFable and XSSable, i will do an CSRF to retrieve money from the user to my account.
So even if my application is XSSable i will my transfer application totaly safe against CSRF…
That’s why i think that a CSRF protection must be safe against XSS attack!

]]> By: Kanatoko http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-11839 Kanatoko Sun, 01 Apr 2007 13:10:45 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-11839 Hong I think that you are missing the point. MHTML bug can be prevented at the server side as same as XSS. Hong

I think that you are missing the point.
MHTML bug can be prevented at the server side as same as XSS.

]]> By: Hong http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-11694 Hong Sun, 01 Apr 2007 07:45:21 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-11694 Kanatoko, Because MHTML bug breaks the same origin policy. If you do not have any XSS flaw on site A, then you cannot access anything on site A, MHTML bug can make you able to access site A even if site A does not has any XSS flaw. Kanatoko,
Because MHTML bug breaks the same origin policy. If you do not have any XSS flaw on site A, then you cannot access anything on site A, MHTML bug can make you able to access site A even if site A does not has any XSS flaw.

]]> By: Kanatoko http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-11645 Kanatoko Sat, 31 Mar 2007 23:36:04 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-11645 <blockquote>the MHTML bug is more dangerous than XSS</blockquote> Interesting. Why? I think XSS( and Session Hijack) is more dangerous than the MHTML bug because it can access to the response of POST.

the MHTML bug is more dangerous than XSS

Interesting. Why?

I think XSS( and Session Hijack) is more dangerous than the MHTML bug because it can access to the response of POST.

]]> By: pagvac http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-11639 pagvac Sat, 31 Mar 2007 20:09:31 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-11639 owasp, There is NO need to put the session IDs within URLs when following this approach. Just include the session ID within form fields that would be transmitted as a POST request, and *not* within URLs: <pre><code><form action="http://target/profile.do" method="POST"> <input type="hidden" name="name" value="John"/> <input type="hidden" name="lastname" value="Dawson"/> <input type="hidden" name="JSPSESSIONID" value="7af7a55caff365ca594510586"/> <input type="submit"/> </form></code></pre> Giorgio Fedon, This might help if you’re paranoid (disable autocomplete): <pre><code><input type="hidden" name="JSPSESSIONID" value="7af7a55caff365ca594510586" autocomplete="off"/></code></pre> But then again, if you can access the user’s machine, you can also access the session ID cookies! Hopefully, the session ID expires after the idle session timeout ends. owasp,

There is NO need to put the session IDs within URLs when following this approach. Just include the session ID within form fields that would be transmitted as a POST request, and *not* within URLs:

<form action="http://target/profile.do" method="POST">
<input type="hidden" name="name" value="John"/>
<input type="hidden" name="lastname" value="Dawson"/>
<input type="hidden" name="JSPSESSIONID" value="7af7a55caff365ca594510586"/>
<input type="submit"/>
</form>

Giorgio Fedon,

This might help if you’re paranoid (disable autocomplete):

<input type="hidden" name="JSPSESSIONID" value="7af7a55caff365ca594510586" autocomplete="off"/>

But then again, if you can access the user’s machine, you can also access the session ID cookies! Hopefully, the session ID expires after the idle session timeout ends.

]]>