Here is my situation, I have an e-commerce site http://www.mydomain.com and my host only supports shared ssl certificates, they do not allow private ssl certificates. In order to easily keep the php session going for the shopping cart on the secure server which is https://mydomain.hostdomain.com, I am redirecting http://www.mydomain.com to http://mydomain.hostdomain.com as my sites address, which works fine.
I would however like to use my actual domain for my site because it would look more professional to customers, but what is the best way to do that? I know I could use http://www.mydomain.com and pass the session id through a url to the secure server and recreate the session there, but I'm wondering if that creates too much of a security risk and if not, what is the best way to do it securely?
Passing Session securely to shared ssl domain
Moderator: General Moderators
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Passing Session securely to shared ssl domain
It is best to never pass the sessionid in the url. Although I've never actually done this before, I would probably look at moving your session storage to the database and writting your own session handler (so you have complete control).
Take a look at session_set_save_handler()
Take a look at session_set_save_handler()
Re: Passing Session securely to shared ssl domain
I already have my session data stored in the database and both mydomain.com and the secure server can use that database, however, my problem is that because different domains can't share the same cookies, the session needs to be recreated with the same session id on the secure server in order to use the same session data.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Passing Session securely to shared ssl domain
If you have the information in the database (assuming both domains share this database), then it would be a simple matter of creating a new session, and populating the new session with the old session data. Step in set_session_save_handler().
Re: Passing Session securely to shared ssl domain
How do you populate the new session with the old session data, without sending the old session id to the secure domain?
Is doing this going to create any security risks?
Is doing this going to create any security risks?
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Passing Session securely to shared ssl domain
I would create a one time key that will effectively tie them together during the transition, and them be removed. Similiar to passing the session id, however, the lifespan of this one time pad typically is only few seconds (and more secure).
Like I said, I have not done this before. I would wait to here on someone with such experience before trying to implement it, but should work.
Like I said, I have not done this before. I would wait to here on someone with such experience before trying to implement it, but should work.
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Passing Session securely to shared ssl domain
http://fi.php.net/manual/en/function.setcookie.php
The bad thing is, the cookie will be sent for all subdomains of your host... and you would need to create two cookies for both domain.com and host.com
So, cookies are no help for us. You have to implement a connection that sends the session id.
Because cookies don't work for the domain.com, so you need to pass it through POST / GET. That's the only way that I'm aware of. The session identifier will be in the URL bar if you are using GET which ain't good either, POST would require JavaScript and these go through unsecured connection that a man-in-the-middle can read.
Like already said, creating a temporary key to make a new session from old is the only way. Only reasonable way that I can think of.
If there's someone on the same route reading the packets, he will get the temporary key and use it himself to get into the customer's shopping cart at SSL'ed page. He could order a couple of more items and checkout. So, you need additional protection. Only allow the same IP between the transistion. Only allow the same user agent. This still isn't 100% safe, since the IP may be same if they are using the same wireless connection and the user agent is easily stolen, too.
So man get a better host and all your troubles are gone
After some thinking. You can't have what you want as in terms of fully secure. You can either get a host that supports private SSL, use the other domain, or not ask for private details such as CC, etc. If your shopping cart items can only be boought through eg PayPal - the attacks are not danger since the attacker needs his PayPal account too
If you are using sensitive information such as the credit card, you must be using private SSL.
When the customer logins at your website, the session is created (and is stored on the db). The cookie is created for the domain. Now when he goes to the shopping cart, it redirects him to the SSL page domain.host.com and when he goes there, the cookie is provided by the web browser, because the domain matches. Then the secure site knows the session and can continue operation.domain
The domain that the cookie is available. To make the cookie available on all subdomains of example.com then you'd set it to '.example.com'. The . is not required but makes it compatible with more browsers. Setting it to http://www.example.com will make the cookie only available in the www subdomain. Refer to tail matching in the » spec for details.
The bad thing is, the cookie will be sent for all subdomains of your host... and you would need to create two cookies for both domain.com and host.com
So, cookies are no help for us. You have to implement a connection that sends the session id.
Because cookies don't work for the domain.com, so you need to pass it through POST / GET. That's the only way that I'm aware of. The session identifier will be in the URL bar if you are using GET which ain't good either, POST would require JavaScript and these go through unsecured connection that a man-in-the-middle can read.
Like already said, creating a temporary key to make a new session from old is the only way. Only reasonable way that I can think of.
If there's someone on the same route reading the packets, he will get the temporary key and use it himself to get into the customer's shopping cart at SSL'ed page. He could order a couple of more items and checkout. So, you need additional protection. Only allow the same IP between the transistion. Only allow the same user agent. This still isn't 100% safe, since the IP may be same if they are using the same wireless connection and the user agent is easily stolen, too.
So man get a better host and all your troubles are gone
After some thinking. You can't have what you want as in terms of fully secure. You can either get a host that supports private SSL, use the other domain, or not ask for private details such as CC, etc. If your shopping cart items can only be boought through eg PayPal - the attacks are not danger since the attacker needs his PayPal account too
If you are using sensitive information such as the credit card, you must be using private SSL.