SESSIONS and HTTPS

[johnsmith153]

Hi. I have average php knowledge. I am using $_SESSION and wondering how often I should use https SSL to ensure data sent can not be intercepted. For example Facebook, ebay and all these only use https when you are logging in and editting personal info. All other actions, including posting messages with your id are http. Are they designed differently?

 

I cram all sorts of info in my $_SESSION, including the username and password.

 

Should certain info, i.e their display name, be stored in a local cookie or something, or is it ok to use $_SESSION.

 

But I am concerned that every page I go on will need the https??

 

Also, every task that requires a login, I have the system check with the database. So if user logged in and the $_SESSION says they are, I always have these values checked in the database for security.

 

So why do Facebook NOT need to use https when posting messages etc, as I am sure I will need to.

 

Please explain as basic as possible and thank you for any help.

[dptr1988]

All data in the $_SESSION variable stays on your server and is very secure.

 

The only way to mess with sessions is to try to get a different session ID, which is pretty hard to do.

 

Even if a use does get a different session ID, he will still not be able to modify the session variables, he is just using somebody else's session id which would mean he appeared to be logged in as a different user.

 

Wikipedia: http://en.wikipedia.org/wiki/Session_fixation

[Daniel0]

The reason why Facebook would use SSL when logging in is so the username and password could not be intercepted, not so the session id wouldn't be intercepted. The contents of $_SESSION is stored on the server, so there is no chance that it would be intercepted between the server and the client. There is no reason whatsoever why you would want to store the password in a session variable though. If you are worried about session fixation by people getting the session id when it's being sent between the client and the server then you should always use SSL.

[johnsmith153]

Two replies so quickly. I thought I would try this board first time today. Very good.

 

I am still a little confused, and I have honestly spent quite a lot of time looking at this.

 

I fully understand all types of hacking on session ids, including session fixation etc. - I also understand session variables are stored on the server. Maybe my main question is obvious!

 

Daniel0 you say there is no reason to store password in session variable. I have been told to store username and password, then use these just before you acces mySQL database to double check this is valid. Are you saying to just store, say a username and for example a unique record id, then use these to ensure that a record exists?

 

Daniel0 also mentioned about using SSL to encrypt when sending sessionid - I suppose the key question is: How often does it send session id? i.e is this only when you have session_start(); at the top of the php page, or every page that you view after log in.

 

I can understand Facebook (as example and I am sure all others do similar) use https to send login details. Then (I think) the user's browser holds the session key. You could view other info that is publicly available over http (as no security problems.) But then, as soon as you want to do something that requires login details, surely you need to use https to send/check/receive etc. Facebook allows you to add info to your profile using http. (so why can this not be picked up by anyone sniffing the network traffic???)

 

Also, if I have used $_SESSION for things like setting a users display name (which will be needed on EVERY page, as I show this in top left corner of every page) - should I use a method different than $_SESSION for the display name?? I,e at moment I am thinking I can get away with http, but will it be sending sessionid etc. that I didn't expect?

 

Thank you if your still reading!!

[codexx]

Hey, I'll just toss in a quick words of my own haha.

 

The reason HTTPS is used for the initial transfer of password data is because it is passed to php in clear text. If you were to use a packet sniffer or sniffing app on a network with someone who is logging in you get their username and password.

 

To protect against session hacking I personally do the following.

 

login page is on HTTPS. Username and Pass is passed to the login function..

 

If the login is valid it..

Stores their userID and username in the $_SESSION

Script updates the USER table in the database and tells it the Browser, IP and a MD5 version + fish of the session_id() of the user. This way if the session is hijacked it terminates it when the browser or IP change.

 

The database is ONLY updated in the login script, and thats the only time a password is ever passed or stored.

 

At the top of every page after session_start() I run a function to make sure the session matches the database values, if they don't it gets terminated. If someone is sending a private message it could still be picked up by a sniffer, so if your concerned about your private messages you can use HTTPS just for the send part. Worst case is someone will see it, not be able to tamper or modify.

 

Hope this helped a bit..

[Daniel0]

You should just store the users id, then you can fetch the information from the database you need on each page. The session id is sent on each request regardless of whether you put session_start() or not. It's stored in a cookie on the user's computer or in the URL if cookies are not possible. You shouldn't make the session dependent on the IP as some users' IP addresses change after only a few requests. AOL users in particular.

[johnsmith153]

I think I now understand.

 

Thank you to all for taking the time.

 

Just finally...

 

Facebook and Ebay (and many others I am sure) only use https when a user sends password, username and personal details.

 

Does that mean someone can easilly pick up a session id (as it would be transmitted in plain text.) by sniffing the network.

 

Dont worry i am not looking to hack Facebook. I suppose if this is acceptable to them, it will certainly be acceptable to me.

[Daniel0]

Technically, yes, the session id could be caught while in transit between the client and server. It's likely that Facebook and eBay have other sorts of things guarding it. They could for instance generate it at each request so it would be useless if somebody intercepted it as it would quickly change again. The username and password is much more valuable than a session id because those two together could create valid sessions for whoever that possesses them.