[Resolved] Secure to UNSECURE data

perpetualshaun

I am trying to pass session variables from throughout my site whether they pull up a page w/ [url]http://[/url] or [url]https://.[/url] I found this code on a forum here:

if(isset($_GET["sess"])) {
	$session = $_GET["sess"];
	session_id($session);
}
session_start();

This works for passing everthing in the session from the [url]http://[/url] to the [url]https://,[/url] but not the other way around. How can I pass them the other way?

Thanks,

Shaun

rachel2004

When you do a session_start(), a session id is generated randomly and is stored on both the client side and the server side. As long as you have a session_start() on each page of your site, there is nothing more that you need to do to move from page to page (of course, depending on your php.ini settings) with that session id, regardless of whether that page is being trasferred over SSL (which is https as you know) or unencrypted (via http).

The snippet that you posted makes the assumption that the session id is being appended in the URL string. That is not secure.

TruckStuff

Originally posted by rachel2004
When you do a session_start(), a session id is generated randomly and is stored on both the client side and the server side. As long as you have a session_start() on each page of your site, there is nothing more that you need to do to move from page to page

This is only true if your HTTP and HTTPS have the same server name, in my experience. In other words, if your server name is server.mydomain.com, and your SSL certificate is for server.mydomain.com, that you are OK. However, if your HTTPS server has a different name, you will have problems. This is very common in shared hosting environments, e.g. you have http://www.mydomain.com but your SSL server is https://ssl.myhost.com/username.

I get around this by basically re-logging in when jumping for HTTP to HTTPS or vice versa. The user's credentials are POSTed to a page on the HTTPS site and if validated, the user is then redirected to the page they were trying to get to. Because the user is re-authed, the same session data then follows them through there HTTPS session. The same thing happens when going from HTTPS to HTTP.

rachel2004

TruckStuff, I completey agree with your first paragraph. You're correct that the server's digital certificate will generally point to a specific domain name or sub-doman name. I should've mentioned that.

From your second paragraph, it looks like on your sites you treat "restricted" content as meaning the same thing as being https. (By all means, I'm not trying to argue with you--you know your site better than me, so I'm just responding to what you wrote). To me, a session_id, privilege escalation, and using SSL are not forced to be tied together, although they are used together.

From what it looks like you said in your second paragraph, you use HTTPS only in those instances when a user is gaining an esalation in privileges. Maybe the user is alredy logged into the site (maybe by a cookie or by explicitly logging in at some point during his visit to your site) and can browse your product catalog, for example, but when he wants to edit his account settings, he needs to be reauthenticated AND THAT'S WHEN you use HTTPS. (Maybe that's not what you were saying, but that's how I interpreted, so please feel free if I misunderstood). Well, to me, you should be using https each time the user is logging into the site, UNLESS the latency of serving pages securely is not worth it (notice that Yahoo mail generally does not use SSL when you login to check you mail, but they do have a link if you the user want that security).

As far as Shaun's original question of going from https back to http, this is just a change in choosing to use SSL to not using SSL. Consider using session_regenerate_id when you have a change in privileges.

TruckStuff

Rachel-
We have system that has basically turned into a complete management system for our business. We have everything from content management for our store front to order processing and accounting. The same domain also hosts content that is publicly accessible.

In order to access our managmenet system, the user must log in at a login page. The username and pass are authenticated against a DB which then pulls down various other settings (access rights, user ID, etc). All of this information may/may not be used in the course of processing the rest of the page, but its a standard set of information for all pages. This process is repeated at the beginning of every page on our site, whether secure or not. So all of our system's pages begin with the following:

<?
require_once ('./load-libs.php');  // Load essential library files
session_start();  // Grab the user's credentials
checkValidUser();  // Where all of the authentication takes place

displayHeader();

// Page content here

displayFooter();
?>

User credentials are stored as session variables then the user is re-authed on every page load. This may be a bit of an overkill, however it allows us to do thinks like lock a user out, shutdown a part of the site, or update a user's access rights without the user having to logout and login again. The processing is almost exactly the same whether or not all of the access rights are updated on every load, so there isn't any performance hit by doing this.

Now for HTTP vs. HTTPS. We have our system broken down into different "realms", e.g. Operations, Accounting, Admin, etc, etc. Some of these areas don't deal with sensitive content, e.g. the "Home" area. Other areas, such as accounting, do display sensitive information. (I suppose we could simply put the entire site on SSL, but that was just a design decision on our part.)

Our users have to be able to jump from HTTP to HTTPS and back transparently without any glitches. Originally, we were simply using the same session variables when jumping between the two. This worked OK most of the time, but we started running into bizarre authentication problems when jumping from one to the other. It was at that point that we realized it was a server name issue. We adopted the approach mentioned above, and it works extremly well regardless of the environment. In other words, we have a development platform and "live" platform, and this solution allows us to jump back and forth on any site, any where simply by changing the target URL of the jumps.

perpetualshaun

Thanks for all the feedback. Unfortuanately, it still isn't working for me after another hour of trials and tests this morning.

I am NOT changing domain names. When I login at https://mydomain.com/login.php and I pull in my validate_login_inc.php file, I am setting all the appropriate session variables, and then passing over to http://mydomain.com.

At the top of the mydomain.com, I did the print_r($_SESSION) thing and none of the user variables that I set at the login are in there. As I said, it works going the other way and I even added the php_flag session.cookie_secure On to my .htaccess file, but still no luck. ARRGHH!!!

Any ideas?