Cross domain sessions

Hi,

I'm building a shopping cart system, which is almost complete if it wasn't
for this bug (grrr). The site has about 10 domains pointing to it, one
domain example-secure.com has the SSL cert, when the customer goes to the
buy form, they're transfered to the secure domain... When this happens the
session data is lost... I presume this is because of the domain transfer?
However, I was under the impression that PHP sets the session cookie to be
non domain specific by default?

Has anybody encountered this problem before, and if so, can suggest a
workaround?
I've thought of a fudge, but I don't really want to be introducing fudges to
a CC handling cart, if at all possible. ;o)

Thanks,

Nathan

Treefrog wrote:
> Hi,
>
> I'm building a shopping cart system, which is almost complete if it wasn't
> for this bug (grrr). The site has about 10 domains pointing to it, one
> domain example-secure.com has the SSL cert, when the customer goes to the
> buy form, they're transfered to the secure domain... When this happens the
> session data is lost... I presume this is because of the domain transfer?
> However, I was under the impression that PHP sets the session cookie to be
> non domain specific by default?

AFAIK cookies are exclusively either domain or host specifik. And the
only thing you would get from a session cookie is the session-id, which
would mean nothing to other servers.


> Has anybody encountered this problem before, and if so, can suggest a
> workaround?

Behavior by design :). You would need other mechanism to transfer
session data. Could be through server to server connections or via
client in formdata. Possibly many ways to do it. Perhaps companies like
Gator has a readymade solution for you, they seem to be sometimes
annoyingly resourceful in that area.


> I've thought of a fudge, but I don't really want to be introducing fudges 
to
> a CC handling cart, if at all possible. ;o)

As long as its only shopping-cart items, I think it would be ok to slack
on security without calling it a fudge, provided to customer has
opportunity to confirm the transfered items.


/Bent

Treefrog wrote:

> I'm building a shopping cart system, which is almost complete if it wasn't
> for this bug (grrr). The site has about 10 domains pointing to it, one
> domain example-secure.com has the SSL cert, when the customer goes to the
> buy form, they're transfered to the secure domain... When this happens the
> session data is lost... I presume this is because of the domain transfer?
> However, I was under the impression that PHP sets the session cookie to be
> non domain specific by default?

Cookies are domain specific by design. A cookie set on one domain will not
be passed to another. However, you can pass cookies across subdomains eg
foo.domain.com and bar.domain.com

> Has anybody encountered this problem before, and if so, can suggest a
> workaround?
> I've thought of a fudge, but I don't really want to be introducing fudges
> to a CC handling cart, if at all possible. ;o)

This is a common issue, as many shopping cart sites have a different domain
for the secure portion (because they're using a shared/virtual hosting
solution and their provider provides the secure cert).

Generally the way around it is whenever you pass from the non secure part of
the site to the secure part and vice-versa you pass the session code in the
url string eg www.domain.com/foo.php?id=session-code-here

You can either continue to pass the session code in the url for all secure
pages, or set a cookie for the secure domain as well if one is not already
set. It's generally safer to keep passing the session code while in the
secure part of the site to ensure they don't lose their shopping cart due
to cookie conflicts.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

Chris Hope wrote:

> Treefrog wrote:
> 
>
>
> Generally the way around it is whenever you pass from the non secure part
> of the site to the secure part and vice-versa you pass the session code in
> the url string eg www.domain.com/foo.php?id=session-code-here
>

But doesn't this leave the door wide open to session fixation amd other
exploits?

If you control both ends then a better solution might be to pass the session
id (with some time varying data - e.g. time - to allow for expiry) in an
encrypted format (symmetric or asymmetric) then decrypt & validate at the
receiving end before reinstating the session using a cookies only policy.
I'm just talking off the cuff here - it needs a lot more thought to make
sure it's secure.

HTH

C.

"Chris Hope" <blackhole@electrictoolbox.com> wrote in message
news:1097780476_21010@216.128.74.129...
> Treefrog wrote:
> 
>
> Cookies are domain specific by design. A cookie set on one domain will not
> be passed to another. However, you can pass cookies across subdomains eg
> foo.domain.com and bar.domain.com
> 
>
> This is a common issue, as many shopping cart sites have a different
> domain
> for the secure portion (because they're using a shared/virtual hosting
> solution and their provider provides the secure cert).
>
> Generally the way around it is whenever you pass from the non secure part
> of
> the site to the secure part and vice-versa you pass the session code in
> the
> url string eg www.domain.com/foo.php?id=session-code-here
>
pass a temporary session id between the servers.

Original session id: ABCD  www.domain1.com
-> Generate a temp ID: transer_bbc that has a value of
original session ABCD
Secure server recieves temp ID. transfrer_bbc -> reads the ABCD session
ID and destroys the temporary transfrer_bbc.

This way the session fixation will be minimized since the ID that you just
passed in the url gets destroyed as soon as secure server grabs it.

?? Any thoughts on this


> You can either continue to pass the session code in the url for all secure
> pages, or set a cookie for the secure domain as well if one is not already
> set. It's generally safer to keep passing the session code while in the
> secure part of the site to ensure they don't lose their shopping cart due
> to cookie conflicts.
>
> --
> Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
>