Comments on: Cookie cunundrum http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/ The personal blog of Jeffrey T. Darlington, creator of General Protection Fault Sat, 05 Dec 2009 02:07:38 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Jeff http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-169 Jeff Wed, 05 Mar 2008 13:28:25 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-169 A signed (HMAC) SHA-256 hash to be precise, encoded with a modified Base64. Again, hopefully not giving too much away about the implementation, the hash is of rest of the cookie contents, scrambled in various ways, and salted with a number of unknown (to the end user) elements. The salt should prevent an attacker from trying various permutations of the raw data to fake the hash. It's a really good way of storing the data in the open and still preventing tampering. Of course, I was already using a separate constant as part of the salt, so pulling information from the <code>$_SERVER</code> array was probably overkill and obviously introduced problems. Then again, sometimes good security is all about overkill. ;) I've since tested the modified code in Firefox 2, IE 6, Opera 9, and Safari 3(?), all for Windows. That should probably be enough to call it a success. I'd still prefer to check it in IE 7 as well as a couple browsers in Linux, but it should be sufficient to move forward. Again, many thanks to all. A signed (HMAC) SHA-256 hash to be precise, encoded with a modified Base64. Again, hopefully not giving too much away about the implementation, the hash is of rest of the cookie contents, scrambled in various ways, and salted with a number of unknown (to the end user) elements. The salt should prevent an attacker from trying various permutations of the raw data to fake the hash. It’s a really good way of storing the data in the open and still preventing tampering. Of course, I was already using a separate constant as part of the salt, so pulling information from the $_SERVER array was probably overkill and obviously introduced problems. Then again, sometimes good security is all about overkill. ;)

I’ve since tested the modified code in Firefox 2, IE 6, Opera 9, and Safari 3(?), all for Windows. That should probably be enough to call it a success. I’d still prefer to check it in IE 7 as well as a couple browsers in Linux, but it should be sufficient to move forward. Again, many thanks to all.

]]> By: bugstomper http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-168 bugstomper Wed, 05 Mar 2008 05:35:19 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-168 Great news! I figured from the length and look of the field that was different that it was a SHA-256 hash of something and that it had to include a field that was sensitive to the http/https difference, but of course with no way to guess what you are hashing together there was no way to reverse engineer past that point. Coincidentally, I'm just starting a job for a client in which I'm doing my first https form, and investigating this was a big help for me. Thanks Jeff! :-) Great news! I figured from the length and look of the field that was different that it was a SHA-256 hash of something and that it had to include a field that was sensitive to the http/https difference, but of course with no way to guess what you are hashing together there was no way to reverse engineer past that point.

Coincidentally, I’m just starting a job for a client in which I’m doing my first https form, and investigating this was a big help for me. Thanks Jeff! :-)

]]> By: Jeff http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-167 Jeff Wed, 05 Mar 2008 02:32:32 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-167 That did it, bugstomper. When I removed SERVER_SIGNATURE out of the mix, the hash became consistent across the HTTP/HTTPS barrier. I've written a new cookie hashing algorithm that should be more stable when switching modes and was able to test it. I successfully set a cookie in HTTPS mode and then read it via HTTP, which is exactly what I wanted. I'll need to modify my code to get this to work, which should be pretty simple as the function exists in a include file that gets called everywhere it's needed. The bad part is that this change will break all the existing Premium cookies, so subscribers will have to re-enable their browsers once it goes into effect. I'll make the changes, test them, then notify the subscribers before I make the change. Thanks everyone for your assistance. You came up with a lot of good ideas for what went wrong and solutions to fix them. Unfortunately, my problem was somewhere between the chair and the keyboard. ;) That did it, bugstomper. When I removed SERVER_SIGNATURE out of the mix, the hash became consistent across the HTTP/HTTPS barrier. I’ve written a new cookie hashing algorithm that should be more stable when switching modes and was able to test it. I successfully set a cookie in HTTPS mode and then read it via HTTP, which is exactly what I wanted.

I’ll need to modify my code to get this to work, which should be pretty simple as the function exists in a include file that gets called everywhere it’s needed. The bad part is that this change will break all the existing Premium cookies, so subscribers will have to re-enable their browsers once it goes into effect. I’ll make the changes, test them, then notify the subscribers before I make the change.

Thanks everyone for your assistance. You came up with a lot of good ideas for what went wrong and solutions to fix them. Unfortunately, my problem was somewhere between the chair and the keyboard. ;)

]]> By: Jeff http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-166 Jeff Tue, 04 Mar 2008 21:26:41 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-166 Without giving away too many details, the Premium cookie contains a signed hash of several values to provide a validation check to prevent tampering or stealing of the cookie. However, the HTTP host value is part of that hash, so "www.gpf-comics.com" and "gpf-comics.com" would produce different hashes, and thus a cookie set by "www.gpf-comics.com" would not be valid if read by "gpf-comics.com". So in that place the validation would indeed fail. It might be a short term problem to contend with, but as previously stated HTTP requests to "gpf-comics.com" will eventually automatically redirect to "www.gpf-comics.com", so this shouldn't be an issue by the end of the month. That, however, shouldn't be an issue with HTTP vs. HTTPS. The protocol isn't included in this host value, so it shouldn't matter whether you access it via "www.gpf-comics.com" or "gpf-comics.com". For that matter, the SSL certificate is for "www.gpf-comics.com", so you shouldn't even be able to access the site in HTTPS mode at "gpf-comics.com" without producing certificate errors. <strong><em>However,</em></strong> also included in the hash as part of the "hidden" data (to add some entropy and salt to the value) is <code>$_SERVER['SERVER_SIGNATURE']</code>, which <em>is</em> different when accessed via HTTP or HTTPS ("Port 80" vs. "Port 443"). That would be just enough to throw the hash off and make it different. This <em>could</em> be the magic bullet. I'll run a couple tests as soon as I can to see if that solves the problem and report back with the findings. Without giving away too many details, the Premium cookie contains a signed hash of several values to provide a validation check to prevent tampering or stealing of the cookie. However, the HTTP host value is part of that hash, so “www.gpf-comics.com” and “gpf-comics.com” would produce different hashes, and thus a cookie set by “www.gpf-comics.com” would not be valid if read by “gpf-comics.com”. So in that place the validation would indeed fail. It might be a short term problem to contend with, but as previously stated HTTP requests to “gpf-comics.com” will eventually automatically redirect to “www.gpf-comics.com”, so this shouldn’t be an issue by the end of the month.

That, however, shouldn’t be an issue with HTTP vs. HTTPS. The protocol isn’t included in this host value, so it shouldn’t matter whether you access it via “www.gpf-comics.com” or “gpf-comics.com”. For that matter, the SSL certificate is for “www.gpf-comics.com”, so you shouldn’t even be able to access the site in HTTPS mode at “gpf-comics.com” without producing certificate errors.

However, also included in the hash as part of the “hidden” data (to add some entropy and salt to the value) is $_SERVER['SERVER_SIGNATURE'], which is different when accessed via HTTP or HTTPS (“Port 80″ vs. “Port 443″). That would be just enough to throw the hash off and make it different. This could be the magic bullet. I’ll run a couple tests as soon as I can to see if that solves the problem and report back with the findings.

]]> By: bugstomper http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-165 bugstomper Mon, 03 Mar 2008 18:54:09 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-165 I noticed the change in the GPF_NEWS cookie during my tests, and my results are with the new PHP version of the cookie. The http and https, both with and without 'www.' all work fine and together with a single cookie for GPF_NEWS but not for Premium. So there is something you are doing differently between the two. In Premium, the cookie domain is properly set to '.gpf-comics.com' and works with and without www, but the Content field of the cookie is being set differently with and without www, making the cookies different. I suspect that if you figure out why Premium's www and non-www cookie Content fields are different you will find out what the problem is with https. I noticed the change in the GPF_NEWS cookie during my tests, and my results are with the new PHP version of the cookie. The http and https, both with and without ‘www.’ all work fine and together with a single cookie for GPF_NEWS but not for Premium. So there is something you are doing differently between the two.

In Premium, the cookie domain is properly set to ‘.gpf-comics.com’ and works with and without www, but the Content field of the cookie is being set differently with and without www, making the cookies different. I suspect that if you figure out why Premium’s www and non-www cookie Content fields are different you will find out what the problem is with https.

]]> By: Jeff http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-164 Jeff Mon, 03 Mar 2008 13:43:15 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-164 The problem with the News Notification cookie is that, depending on when it was last set, it was probably set by JavaScript (the only option available to me at Keenspot) where as Premium is being set via PHP. The News cookie is now also being set by PHP setcookie(). It looks like the News cookie properly updated with today's News update, according to a quick check of my cookies. As far as I know, there shouldn't be any difference between how the News and Premium cookies are now being set, so it might be interesting to try your test again, now that the News cookie is being set via PHP. On "gpf-comics.com" vs. "www.gpf-comics.com": I should point out that before long URLs at "gpf-comics.com" will eventually be redirected to the comparable URL at "www.gpf-comics.com". This is primarily to help search engine optimization and such, and since I actually do have sub-domains the "www." is still significant. Those redirects aren't in place yet because they will conflict with supporting the beta test domain, but once the beta test domain goes away and all its URLs redirect to "www.gpf-comics.com" URLs, the "gpf-comics.com" URLs will redirect as well. That said, all the cookies should be set for ".gpf-comics.com", meaning it should work for any sub-domain. Thus it <em>should</em> work regardless of whether the "www." is there or not. Unfortunately, I haven't had time to test this at all. I'll see what I can do, but now that we've launched the site it will probably be a lower priority for a bit. The problem with the News Notification cookie is that, depending on when it was last set, it was probably set by JavaScript (the only option available to me at Keenspot) where as Premium is being set via PHP. The News cookie is now also being set by PHP setcookie(). It looks like the News cookie properly updated with today’s News update, according to a quick check of my cookies. As far as I know, there shouldn’t be any difference between how the News and Premium cookies are now being set, so it might be interesting to try your test again, now that the News cookie is being set via PHP.

On “gpf-comics.com” vs. “www.gpf-comics.com”: I should point out that before long URLs at “gpf-comics.com” will eventually be redirected to the comparable URL at “www.gpf-comics.com”. This is primarily to help search engine optimization and such, and since I actually do have sub-domains the “www.” is still significant. Those redirects aren’t in place yet because they will conflict with supporting the beta test domain, but once the beta test domain goes away and all its URLs redirect to “www.gpf-comics.com” URLs, the “gpf-comics.com” URLs will redirect as well.

That said, all the cookies should be set for “.gpf-comics.com”, meaning it should work for any sub-domain. Thus it should work regardless of whether the “www.” is there or not. Unfortunately, I haven’t had time to test this at all. I’ll see what I can do, but now that we’ve launched the site it will probably be a lower priority for a bit.

]]> By: bugstomper http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-162 bugstomper Mon, 03 Mar 2008 12:26:33 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-162 More clues: I installed the editcookie addon in Firefox to make it easier to look at the cookies, and did the following experiment: 1. Go to http://gpf-comics.com/premium log in to my Premium account, click on the button to enable Premium in my browser, then look at and save the Content of the gpf_premium cookie. 2. Then go to http://www.gpf-comics.com/premium, notice that I am not logged in, login to my Premium account, click on the button to enable Premium in my browser, then look at and save the Content of the gpf_premium cookie. It is different than in step 1. 3. Repeat step 1. Verify that the content of the cookie is the same as in step 1. 4. Repeat step 2. Verify that the Content of the cooke is the same as in step 2. More clues: I installed the editcookie addon in Firefox to make it easier to look at the cookies, and did the following experiment:

1. Go to http://gpf-comics.com/premium log in to my Premium account, click on the button to enable Premium in my browser, then look at and save the Content of the gpf_premium cookie.

2. Then go to http://www.gpf-comics.com/premium, notice that I am not logged in, login to my Premium account, click on the button to enable Premium in my browser, then look at and save the Content of the gpf_premium cookie. It is different than in step 1.

3. Repeat step 1. Verify that the content of the cookie is the same as in step 1.

4. Repeat step 2. Verify that the Content of the cooke is the same as in step 2.

]]> By: bugstomper http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-161 bugstomper Mon, 03 Mar 2008 11:39:15 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-161 I juat signed up for GPF Premium and took a look at the cookie you use. It already has path='/' so my suggestion to try that won't help. But here might be a clue. Whatever you are doing for the GPF_NEWS cookie works fine. I can go to any of http://www.gpf-comics.com http://gpf-comics.com https://www.gpf-comics.com https://gpf-comics.com and they all see my GPF_NEWS cookie. However, with GPF Premium, not only does https not work to see the gpf_premium cookie, but here is a new clue: http://gpf-comics.com/premium does not use the cookie made by going to http://www.gpf-comic.com and vice-versa, even though the cookies look the same when I look at them in Firefox and they do overwrite each other. So maybe you can try to figure out why the premium cookie for gpf-comics.com overwrites but is not compatible with the one from www.gpf-comics.com I juat signed up for GPF Premium and took a look at the cookie you use. It already has path=’/’ so my suggestion to try that won’t help.

But here might be a clue. Whatever you are doing for the GPF_NEWS cookie works fine. I can go to any of http://www.gpf-comics.com http://gpf-comics.com https://www.gpf-comics.com https://gpf-comics.com and they all see my GPF_NEWS cookie.

However, with GPF Premium, not only does https not work to see the gpf_premium cookie, but here is a new clue: http://gpf-comics.com/premium does not use the cookie made by going to http://www.gpf-comic.com and vice-versa, even though the cookies look the same when I look at them in Firefox and they do overwrite each other. So maybe you can try to figure out why the premium cookie for gpf-comics.com overwrites but is not compatible with the one from http://www.gpf-comics.com

]]> By: bugstomper http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-160 bugstomper Mon, 03 Mar 2008 06:46:25 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-160 This is a long-shot, but try explicitly setting the cookie path to '/'. I seem to recall reading about a similar problem that was solved by doing that even though it wasn't clear why that worked as the URL path was supposed to be identical for the http and the https URLs. This is a long-shot, but try explicitly setting the cookie path to ‘/’. I seem to recall reading about a similar problem that was solved by doing that even though it wasn’t clear why that worked as the URL path was supposed to be identical for the http and the https URLs.

]]> By: Jeff http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/comment-page-1/#comment-159 Jeff Thu, 21 Feb 2008 13:58:58 +0000 http://www.jeffdarlington.com/2008/02/06/cookie-cunundrum/#comment-159 Thanks for the input, guys, and sorry for taking so long to respond. Unfortunately, none of your suggestions are working. I've tried writing the Set-Cookie header manually, checking all possible avenues for returning the cookie to PHP ($_COOKIE, $_REQUEST, $HTTP_COOKIE_VARS), setting the cookie twice (once in HTTP and again in HTTPS), using separate cookies for HTTP and HTTPS... none of which have worked. I still get the same situation: it sets it for one but won't read it for the other. At this point, I'm at a total loss. I'll be launching the site without HTTPS on the account management stuff for now. The only solution I can come up with something along GreatScott's line: when it comes to actually setting the cookie, bounce them out of secure mode, set the cookie, and bounce them back. Unfortunately, I don't have time to implement a solution that complex. Thanks for the input, guys, and sorry for taking so long to respond. Unfortunately, none of your suggestions are working. I’ve tried writing the Set-Cookie header manually, checking all possible avenues for returning the cookie to PHP ($_COOKIE, $_REQUEST, $HTTP_COOKIE_VARS), setting the cookie twice (once in HTTP and again in HTTPS), using separate cookies for HTTP and HTTPS… none of which have worked. I still get the same situation: it sets it for one but won’t read it for the other.

At this point, I’m at a total loss. I’ll be launching the site without HTTPS on the account management stuff for now. The only solution I can come up with something along GreatScott’s line: when it comes to actually setting the cookie, bounce them out of secure mode, set the cookie, and bounce them back. Unfortunately, I don’t have time to implement a solution that complex.

]]>