Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 19
  1. #1
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Are PHP sessions ever essential?

    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
    Think slow, type fats

  • #2
    UE Antagonizer Fumigator's Avatar
    Join Date
    Dec 2005
    Location
    Utah, USA, Northwestern hemisphere, Earth, Solar System, Milky Way Galaxy, Alpha Quadrant
    Posts
    7,691
    Thanks
    42
    Thanked 637 Times in 625 Posts
    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.

  • #3
    Senior Coder Len Whistler's Avatar
    Join Date
    Jul 2002
    Location
    Vancouver, BC Canada
    Posts
    1,323
    Thanks
    26
    Thanked 100 Times in 100 Posts
    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.
    Leonard Whistler

  • #4
    Regular Coder
    Join Date
    Oct 2005
    Location
    Right Here
    Posts
    654
    Thanks
    1
    Thanked 0 Times in 0 Posts
    Your asking if you can do things without using sessions?

  • #5
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,058
    Thanks
    10
    Thanked 96 Times in 94 Posts
    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
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)

  • #6
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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? Oh well, if it were easy probably none of us would be doing this..

    Thanks again for all the food for thought!
    Think slow, type fats

  • #7
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Len Whistler View Post
    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!
    Think slow, type fats

  • #8
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by iLLin View Post
    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.
    Think slow, type fats

  • #9
    UE Antagonizer Fumigator's Avatar
    Join Date
    Dec 2005
    Location
    Utah, USA, Northwestern hemisphere, Earth, Solar System, Milky Way Galaxy, Alpha Quadrant
    Posts
    7,691
    Thanks
    42
    Thanked 637 Times in 625 Posts
    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).

  • #10
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Fumigator View Post
    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.
    Think slow, type fats

  • #11
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    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.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #12
    New Coder
    Join Date
    Mar 2007
    Posts
    63
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by felgall View Post
    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!
    Think slow, type fats

  • #13
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    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.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #14
    Regular Coder
    Join Date
    Oct 2005
    Location
    Right Here
    Posts
    654
    Thanks
    1
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by RTrev View Post
    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

  • #15
    Regular Coder
    Join Date
    Oct 2005
    Location
    Right Here
    Posts
    654
    Thanks
    1
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by felgall View Post
    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?P...3409adj093jldk

    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.


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •