...

View Full Version : Are PHP sessions ever essential?



RTrev
03-24-2007, 02:56 AM
Some of you might have followed my weird adventures in trying to use sessions without cookies, in the thread entitled "How to never set a cookie??".

In exploring that, a perhaps even more fundamental question arose for me. Are PHP Sessions *ever* truly necessary? Another way of asking the same question might be, is it ever essential to maintain state? Handy, yes. But unavoidable?

I was over in the news.grc.com newsgroups, where some other very sharp cookies (pun intended) hang out, and some of them challenged me on my assumption that sessions, with or without cookies, were ever truly needed. I was at a loss to come up with a single example of something that couldn't be done in PHP/HTML/SQL without the use of a session.

Does anyone have any thoughts on this?

Thanks,
Bob

Fumigator
03-24-2007, 03:06 AM
One of the fun things about PHP (and web development in general for that matter) is the open ended nature of it. Several different ways to get the same thing done. I use sessions to validate pages I only want logged-in members to see, but I'm sure there are other ways to do the same thing. You could maintain logged-in user status in a MySQL table and read that table at the top of every page to see if a user is logged in. But there is a trade-off in convenience and development time, and is it worth it just to avoid cookies? Cookies are so accepted now-a-days (as a somewhat necessary evil) that I don't even worry about it.

IT geeks like us are always making decisions like this. I just had to de-normalize a table at work because it simply runs faster in our most critical batch process as a part of another table, and in that situation it was worth it for us to trade 100% normalization for performance. Our customers don't give a witch's pointy hat if the tables are pure, they just want the batch jobs to be fast.

Len Whistler
03-24-2007, 03:50 AM
Page 255 from PHP and MySQL for dynamic website by Larry Ullman, the 2003 edition.

".......Sessions are more secure than cookies in that all of the recorded information is stored on the server and not continually sent back and forth between server and the client. Second, some users reject cookies or turn them off completely........"

By the way this is a great book and I recommend the new edition, also from Larry Ullman.

iLLin
03-24-2007, 05:04 AM
Your asking if you can do things without using sessions?

firepages
03-24-2007, 09:20 AM
depends what you mean by `needed`

If by needed you mean `why do I need an interpreted language like PHP when I could code it all in Assembly` or `I can do that on an abacus`, then no.

If you mean 'needed' in so far as ease and speed of development then yes they are often 'needed'

One could maintain session state simply by tracking (e.g) POST & GET requests, as long as the user does not leave the page... you might even try some funky IP detection to maintain state which would fall over with the first AOL user.

In the same we now use rubber pneumatic tyres instead of the old wooden wheels (which worked quite well) PHP and many other languages now use sessions to maintain state, like any such system there are pros and cons, in this case for web development the pros far outweigh the cons.

So whilst the guys you are talking to may well be correct that strictly speaking sessions/cookies are not required for many tasks... well strictly speaking you don't need to wear trousers to hurdle a bramble bush... the choice is yours ;)

RTrev
03-24-2007, 02:44 PM
Thanks to all for the good replies. I guess we're always talking about balance, aren't we? I could as easily have asked if we really needed computers. ;)

The folks I've been talking to are probably at one extreme of the spectrum, in which security/privacy are the paramount goals. So their question to me was why use things like sessions and/or cookies unless you have to.

Now I'm hearing a less extreme group saying that a reasonable balance of risk versus payoff is really a more workable goal, especially if productivity is taken into account.

I'll need to find my own balance point, I think, in terms of what the risks really are and which of them are acceptable.. and that means a lot more study about the real nature of those risks, how often they are exploited in the real world, how much extra work is involved in eliminating or reducing each one, the actual value of the material which is exposed to risk in a given case, etc.

I appreciate all of your feedback!

I'm in a position of wanting to find the tools I'll be using later on if/when I begin developing sites for others as a means of extra income and as a hobby. I'm beginning to see that probably one set of hard and fast rules isn't going to work for me. Different solutions for different needs seems to be what I should be looking at. How much "risk" is warranted given the data being stored, the customer's desires, the occasional need to get something up and working fast, how large a security "target" the site in question will be, and on and on.

Probably no easy answers, eh? :rolleyes: Oh well, if it were easy probably none of us would be doing this.. ;)

Thanks again for all the food for thought!

RTrev
03-24-2007, 03:57 PM
Page 255 from PHP and MySQL for dynamic website by Larry Ullman, the 2003 edition.

".......Sessions are more secure than cookies in that all of the recorded information is stored on the server and not continually sent back and forth between server and the client. Second, some users reject cookies or turn them off completely........"

By the way this is a great book and I recommend the new edition, also from Larry Ullman.

Sounds like a book I need! ;) Thanks for the recommendation.

I do wonder about that statement about all information being sent back and forth when cookies are used. I was under the impression that only the session id was stored in the cookie, and that the actual data was still stored server-side using files or memory depending on the server setup.

In any event, some real-world experimenting has shown me something odd, which we go into detail about in that other thread. In short, trying this on three different hosting systems, it seems that the second I create a session a cookie appears on the user's machine. There is no way I can prevent this, that I've found yet. I know this is a server-side configuration option, and that things like use_cookies, use_trans_id, etc., can theoretically be over-ridden via either .htaccess or actual PHP code, but I've found that these are not generally honored by the hosting services. My 1&1 account ignores those, or throws a 500 Apache error if using the .htaccess method. And a buddy tested on two other shared hosting services and found they behaved identically. My wife set up an Ubuntu LAMP server for me to play with, and the defaults of that behaved in the same way. So unless one is able to run their own server, it seems that sessions and cookies go hand-in-hand. No doubt the hosting companies have good reasons for what they're doing, but I can't get 1&1 to communicate with me about it.. so I'm just guessing that they feel that including the session information in the URL is simply too insecure to even consider.

Thanks again.. heading for Amazon to order that book now! :)

RTrev
03-24-2007, 04:10 PM
Your asking if you can do things without using sessions?

Well, I guess I was more asking if anyone could point to something that I absolutely could not do without using sessions.

I guess the basis of my question is that I'm learning.. and one thing that seems central to me is learning best practices for sites in general. So I asked on a security-related newsgroup about how people felt toward session cookies, and most said things to the effect of they are harmless in and of themselves, but because of the rampant abuse of cookies on the web it's generally a good idea to not use them at all if you can manage that. Our visitors do not know us personally, and their impressions will be formed by what they see our site doing. If they see cookies being set, or client-side scripting being used, there's a strike against us right off the bat.

The really clueful will of course accept session cookies, accept first-party cookies but transform them into session cookies which disappear when the browser is closed, and will white-list sites where they find there is some actual advantage to them in keeping a persistant cookie. But the security-conscious and less clueful user will just block all cookies. It seems like an area where it's more trouble to use them than to find ways around them in many cases.

In my case, using sessions means using cookies.. and so as much as I'd like to have that convenience I'm not yet sure it's worth the price of having to set a cookie.

Fumigator
03-24-2007, 05:16 PM
The really clueful will of course accept session cookies, accept first-party cookies but transform them into session cookies which disappear when the browser is closed, and will white-list sites where they find there is some actual advantage to them in keeping a persistant cookie. But the security-conscious and less clueful user will just block all cookies.

It really depends on your demographic. My grandma is going to bake cookies for me, but wouldn't ever think to block cookies on her internet. I could spend a week explaining to her how and why, at the end she'd still just bake em not block em.

Even the friends I have who are internet users but not IT-types wouldn't ever think they needed to block cookies, unless a newspaper article put the fear of the hax0r into their hearts (which happened once a few years back).

RTrev
03-24-2007, 05:34 PM
It really depends on your demographic. My grandma is going to bake cookies for me, but wouldn't ever think to block cookies on her internet. I could spend a week explaining to her how and why, at the end she'd still just bake em not block em.

Even the friends I have who are internet users but not IT-types wouldn't ever think they needed to block cookies, unless a newspaper article put the fear of the hax0r into their hearts (which happened once a few years back).

The problem is that I don't have a demographic. I'm about to retire from 30 years of IT work, but it was all on VMS systems and none of it involved the web. So I'm a newbie. I'm thinking that a few extra bucks on the side during retirement would be a nice thing, and perhaps a fun hobby, but as to my audience I have no clue. Being a bit of a perfectionist I want sites I build to be "right", and I'm in the process of determining what that actually means. The only thing I'm fairly certain of at this point is that it means no client-side scripting, ever, under any conditions. It means the site should be viewable with any reasonably-compliant browser. It means that any personal information is locked down tight. And of course the site must be usable. :D

felgall
03-24-2007, 09:59 PM
If you need to identify a particular visitor across multiple pages then your choices from least secure to most secure are:

1. query string on the end of the address
2. cookies
3. session where only the session id is passed using one of the above two methods

without using one of the above methods there is no way to tell from different pages who it is that is visiting in order to tell if it is the same person.

RTrev
03-24-2007, 10:23 PM
If you need to identify a particular visitor across multiple pages then your choices from least secure to most secure are:

1. query string on the end of the address
2. cookies
3. session where only the session id is passed using one of the above two methods

without using one of the above methods there is no way to tell from different pages who it is that is visiting in order to tell if it is the same person.

Okay, help me with this, because obviously I'm missing a piece. I keep reading that passing the session id as part of the URL is very poor practice because the session can more easily be hijacked, the user may bookmark the page along with the session id, may send the link to someone along with the session id, and so forth. But your last and most secure option seems to include this possibility? Is it simply incorrect that passing a session id with the URL is risky?

What is it that I'm missing here?

Please forgive the "newbie confusion" as I'm not arguing with you, I'm truly confused about this. I can also find absolutely NO way to begin a session without setting a cookie, which complicates things even further for me.

I'm half tempted to simulate a session, by generating a complex hash as my fake session id and then using that to form a global array of some sort. One thing I noticed about PHP sessions is that one can have multiple browser windows open in the same application and they all interact with one another.. presumably because they are reading the same cookie?

Sorry if I'm being dense!

felgall
03-24-2007, 11:46 PM
A session stores all of its data on the server. How it stores it depends on how the session functions are set up on the server and you can override the default ones to store the session fields in a different place on the server (eg. in a database) if you want.

To pass the session between pages requires something on the client end to pass the session id. This will be a cookie if the browser is set to allow session cookies (which are stored in the browser itself and not in a file on their computer) or will be added to the end of the URL if session cookies are not permitted.

You can set up actual session fields on the server that make it almost impossible to hijack a browser session. Certainly if you have a member's only section and are using a session to keep track of who it is that is logged on you can make it harder to hijack the session than to crack their password. This applies regardless of how the session id is passed between pages because there are millions more possible session ids than you are ever likely to have in total members and the hijacker would be required to guess the session id of someone actually currently logged on in order to hijack their session. To hijack a logged in users session where the session id is passed on the URL the hijacker would have to be intercepting all communication between that computer and the internet in which case that person has HUGE security problems as their entire identity has been compromised.

iLLin
03-24-2007, 11:52 PM
Okay, help me with this, because obviously I'm missing a piece. I keep reading that passing the session id as part of the URL is very poor practice because the session can more easily be hijacked, the user may bookmark the page along with the session id, may send the link to someone along with the session id, and so forth. But your last and most secure option seems to include this possibility? Is it simply incorrect that passing a session id with the URL is risky?

What is it that I'm missing here?

Please forgive the "newbie confusion" as I'm not arguing with you, I'm truly confused about this. I can also find absolutely NO way to begin a session without setting a cookie, which complicates things even further for me.

I'm half tempted to simulate a session, by generating a complex hash as my fake session id and then using that to form a global array of some sort. One thing I noticed about PHP sessions is that one can have multiple browser windows open in the same application and they all interact with one another.. presumably because they are reading the same cookie?

Sorry if I'm being dense!

I have built some login systems and this is always a gray area for me. There are methods you can employ to prevent session hijacks through the URL.

One method I use is I check the users browser and build and run that through a encrypt code and MD5. Well obviously if the person is using the same browser this has no effect. But it still adds to some security. And I also store all sessions in the database.

Now from what little I know... is that your really cant have a 100% secure login, you can bump IP's. But this prevents the problem with AOL users... You can also check hostnames, but proxy servers and AOL yet again...

I dont rely on cookies when I build but "I think" that making cookies mandatory would be the most secure login method. Then you can bump the cookie to the session to the browser etc...

Thats just my opinion, anyone else got thoughts :)

iLLin
03-24-2007, 11:56 PM
A session stores all of its data on the server. How it stores it depends on how the session functions are set up on the server and you can override the default ones to store the session fields in a different place on the server (eg. in a database) if you want.

To pass the session between pages requires something on the client end to pass the session id. This will be a cookie if the browser is set to allow session cookies (which are stored in the browser itself and not in a file on their computer) or will be added to the end of the URL if session cookies are not permitted.

You can set up actual session fields on the server that make it almost impossible to hijack a browser session. Certainly if you have a member's only section and are using a session to keep track of who it is that is logged on you can make it harder to hijack the session than to crack their password. This applies regardless of how the session id is passed between pages because there are millions more possible session ids than you are ever likely to have in total members and the hijacker would be required to guess the session id of someone actually currently logged on in order to hijack their session. To hijack a logged in users session where the session id is passed on the URL the hijacker would have to be intercepting all communication between that computer and the internet in which case that person has HUGE security problems as their entire identity has been compromised.

Well users are dumb and they paste there urls places. IE:

Hey guys check this out: http://mydomain.com/funnyfaces.php?PHPSESSID=KJDljd093409adj093jldk

And they click it and BAM stolen session. Now normally your friends aren't going to do damage to you but... that risk is still there.

schleppel
03-25-2007, 01:12 AM
It's easier if you split the last one
Data is in the query string, eg. /file.php?username=abc&encryptedpassword=def
Data is in a cookie.
Session ID is in the query string, eg. /file.php?sid=123abd
Session ID is in the cookie.

#1 and #2 are bad because the actual data is accessible.
#1 and #3 are bad because the data will be saved in bookmarks and copied with links, etc.
#4 does not suffer from those problems.

I don't understand the security/privacy issues with session IDs. You should do checks on IP address (and any forwarded ip address header) and user agent (and probably lots more) when using sessions to stop (most) hijackings and ask for passwords when doing highly sensitive things (changing passwords/email address/secret question). And you can be tracked whatever you do through the server's access logs, having a single cookie on your machine doesn't make it that much easier.

You don't need sessions, but can you imagine going through a shopping website, writing out all the product IDs and filling out a single form to buy it. Or re-authenticating every time you wanted to post to a forum, etc. Sessions are there to help users as much as they are to help programmers.

RTrev
03-25-2007, 01:40 AM
It's easier if you split the last one
Data is in the query string, eg. /file.php?username=abc&encryptedpassword=def
Data is in a cookie.
Session ID is in the query string, eg. /file.php?sid=123abd
Session ID is in the cookie.

#1 and #2 are bad because the actual data is accessible.
#1 and #3 are bad because the data will be saved in bookmarks and copied with links, etc.
#4 does not suffer from those problems.

I don't understand the security/privacy issues with session IDs. You should do checks on IP address (and any forwarded ip address header) and user agent (and probably lots more) when using sessions to stop (most) hijackings and ask for passwords when doing highly sensitive things (changing passwords/email address/secret question). And you can be tracked whatever you do through the server's access logs, having a single cookie on your machine doesn't make it that much easier.

You don't need sessions, but can you imagine going through a shopping website, writing out all the product IDs and filling out a single form to buy it. Or re-authenticating every time you wanted to post to a forum, etc. Sessions are there to help users as much as they are to help programmers.

Ah, thank you.. I think I'm starting to get the idea now. The web thing is a whole different world in some ways from other types of "system management." :eek:

I appreciate the replies! It's hard to get a handle on some of this when first exposed to it, especially when there is so much commentary out there that seems persuasive but basically in disagreement. :)

Thanks again! I'm going to go and ponder for a while, and do a LOT more studying...

felgall
03-25-2007, 02:30 AM
If you set up so that the session id is stored in the login database table while the person is logged in and then deleted from there when they logout or their session expires then once that happens it doesn't matter if the session id is published anywhere because that user/session combination no longer exists and will probably not exist again for a few thousand years (assuming that the particular user keeps logging in and out of the system every few seconds for the thousands of years necessary to go through all the possible session id combinations).

RTrev
03-25-2007, 03:13 AM
If you set up so that the session id is stored in the login database table while the person is logged in and then deleted from there when they logout or their session expires then once that happens it doesn't matter if the session id is published anywhere because that user/session combination no longer exists and will probably not exist again for a few thousand years (assuming that the particular user keeps logging in and out of the system every few seconds for the thousands of years necessary to go through all the possible session id combinations).

Okay, that makes sense. The first detail to occur to me is to wonder what happens if a person logs in, loses their connection for whatever reason, and logs back in a few seconds later. I guess we'd just need to ask for authentication again at that point, and clean up the entry in the table.

I'm beginning to suspect that my stumbling block to understanding all of this has been my failure to comprehend that sessions really need to go hand-in-hand with login authentication. For example, right now I have 10 tabs open in Firefox, and it would be easy to forget and surf to a site I already have open in another tab/window. Trying that on my test site I find that since the same session cookie is being used, the two sessions are both active and interact with one another. If I change a session variable in one, it changes in the other. So even if I'm not dealing with any sensitive of confidential information, things are going to get all screwed up. Especially so if the user sees nothing wrong with running multiple sessions on a given site. This might be a case where the cookie wouldn't be the optimal solution.. unless you do use login authentication. If the session id was being passed by URL they could have as many distinct sessions as they wanted simultaneously without a problem.

Assuming security was *not* the issue, but merely being able to maintain state for the user, who might very well want to be using two different parts of your site simultaneously, the URL would probably work best, right? If they wanted access to a secure or members-only area, then we'd have to log them in formally, with a different session id.. and let them do what they wanted in the other sessions.

Of course a lot of this is moot since I've found that I cannot start a session without a cookie being created (unless, presumably, I ran my own server and had control of things like the trans_id and the use_cookies settings.)

My head is starting to hurt. :) I'd better sleep on this for now. Appreciate your help!!



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum