Comments on: Preventing CSRF http://www.gnucitizen.org/blog/preventing-csrf/ Information Security Think Tank Mon, 12 Dec 2011 19:56:03 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: pdp http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-130045 pdp Wed, 27 Apr 2011 13:47:17 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-130045 Hi Bob, You can still has the cookie with a known salt value in order to prevent leakage. I think the technique is very simple and effective. Hi Bob,

You can still has the cookie with a known salt value in order to prevent leakage. I think the technique is very simple and effective.

]]> By: Bob http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-129909 Bob Fri, 22 Apr 2011 21:04:08 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-129909 I came across this old thread while researching CSRF prevention. It seems to me that the proposed solution on this post is what OWASP calls "double-submit cookies" (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet) OWASP suggests that this solution is effective, but increases risk of session hijacking, and recommends a "synchronizer token" solution. I put the link here in case others come across this thread. I came across this old thread while researching CSRF prevention. It seems to me that the proposed solution on this post is what OWASP calls “double-submit cookies” (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet)
OWASP suggests that this solution is effective, but increases risk of session hijacking, and recommends a “synchronizer token” solution.
I put the link here in case others come across this thread.

]]> By: Preventing CSRF with CsrfGuard | Keep It Locked http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-129664 Preventing CSRF with CsrfGuard | Keep It Locked Thu, 20 Jan 2011 02:14:07 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-129664 [...] type of solution is suggested by some reputable sources in application security. In some cases, the CSRF token is the session [...] [...] type of solution is suggested by some reputable sources in application security. In some cases, the CSRF token is the session [...]

]]> By: pdp http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-129274 pdp Sat, 13 Nov 2010 01:55:36 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-129274 it depends it depends

]]> By: Sumit http://www.gnucitizen.org/blog/preventing-csrf/comment-page-1/#comment-129184 Sumit Thu, 07 Oct 2010 10:23:03 +0000 http://www.gnucitizen.org/blog/preventing-csrf#comment-129184 Is using Security Tokens with URLs Correct Option of Preventing website from XSRF... Is using Security Tokens with URLs Correct Option of Preventing website from XSRF…

]]> 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.....8;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.

]]>