Effective, efficient, foolproof, secure session handling

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

mgelinas
Forum Newbie
Posts: 13
Joined: Tue Jun 10, 2003 6:33 am
Location: QC Canada

Post by mgelinas »

Well, mikusan, I understand that if you set session.use_trans_id to 1 (that is, not 0, thus enabling it) or your web hoster imposes this setting, and you do not implement cookies, PHP will automatically pass on the PHPSESSID parameter from page to page.

It will add the PHPSESSID as a hidden value in each form in the script. If you move from one of your pages to another with a relative URL (staying within your site) and not a form, the PHPSESSID will be appended to the URL as follows: URL?PHPSESSID=[32 gobblygook characters].

Cookies are troublesome, unreliable and often resented by users. Appending to URL makes them look odd and does not provide for valid bookmarks. I have seen such URL in the hundreds of characters. Ugly.

Moving from page to page with the POST method and form buttons is the clean way to do it. Users interact with your script and the URL in their browser may hardly change. They can bookmark it at will as their re-entry later on will be acted upon by the PHP script, if it is smart enough.

To get to a pure HTML page from an PHP page, I implemented an intermediate PHP page that destroys the current session and redirects to the HTML page. This provides for a clean HTML URL with nothing appended.

I bother about the user experience. I bother about nasty cookie and bookmarks side effects. This is not a no-no...
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Welll according to the HTTP Spec, pages reached via POST are not supposed to be bookmarkable. A user's browser would not be incorrect to not allow your pages to be bookmarked. Using form based browser navigation does break back button preformance on several browsers.

It does provide a clean URL, at the expense of a clean UI on the web page itself.

When you say cookies are "troublesome, unreliable, and often resented" I think you are saying the same thing three times. Saying something three times doesn't make it any more true.

Yes cookies are unreliable, because the user may choose to deny them (because they resent them for their privacy tracking effects). The use of troublesome implies either that because they are unreliable, they are troublesome to the developer, or because of the prviacy/tracking issues. So there is a single issue with cookies -- they may be denied by the user.

A developer needs to weigh the decision between:
A. Using and Requiring Cookies
B. Using Cookies with URL mangling fallback
C. Using URL mangling only
D. Using Post with all form-based page transitions
E. Using ip tracking

PHP native sessions allows simple use of A-C with no loss of security, or ease of use, relative to D. Most people know the definate drawbacks of E -- proxies, easy spoofing, etc. Method D also have drawbacks for use in Lynx or text browsers, if that's important to you (probably not for many people). Method D also has drawback from a "web-services" perspective and from a scripted testing perspective.

My main point is that any method pushed as an effective, efficient, foolproof, and secure needs to be:
1. Explicit as to the ramifications of using it (ie form only navigation mentioned up front, and demo'd in the guide)
-- otherwise its not effective, efficient or foolproof
2. Reasonable in terms of CPU use, this method fits here, no complaints
3. If "secure" is mentioned as a selling point, it should be more secure than the default. This method is no more and no less secure than the default.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

mikusan wrote:Now i see what you are saying thanks you cleared some things out for me too, but let me ask you <b>nielsene</b> i wrote my own session handler so that i can use some tricks and so that i can use a database to store the data, when i did that i was sure i have completely overridden the default session handler, that includes session cookies, as you said though that is not the case, then may i ask you, (assuming that i cannot see and or edit php.ini which i can't) then i don't exactly have a cookie sent to my computer when i log in to my site, and i don't have a superlong URL including the php sessid. Then how are my sessions recognized and passed from page to page... how can i override the current cookie session settings?
When you register your own session handler, you do not override the normal cookie/GET propagation of the session ID. Custom session handlers only deal with how name(session variables)=value pairs are stored, whether in a flat file or database, etc.

If you aren't see URL name mangling then cookies are being sent. Perhaps you are accepting cookies automatically from your site? Check your cookie list and see if you see one from your site stored by your browser.

If you want to override the current cookie settings you can use the

Code: Select all

ini_set("session.use_cookies",0);
See http://www.php.net/ini_set for more options that may be set at run-time from the php.ini file. Any option marked with PHP_INI_ALL may be set at run time. If you set this option before the you call session_start() you'll be able to tell PHP not to use cookies, even if you can't modify your site's php.ini file.
mgelinas
Forum Newbie
Posts: 13
Joined: Tue Jun 10, 2003 6:33 am
Location: QC Canada

Post by mgelinas »

To Nielsene. Thanks a lot for your clear meaningful post. I will reconsider my position on cookies. I might implement these after all.

The deal with users would be:

A. Accept my cookies and you will be saved mangled URLs that are inappropriate for bookmarking.

B. Trust that my cookies are not an invasion of your privacy.

C. Be aware that if my server receives no cookie from your browser to identify you (so my pages can be adjusted to your preferences), you will need to identify yourself by entering your username and password.

D. If somebody else uses your computer to connect to my site, the browser will send a cookie causing that person to be mistaken for you.

E. If you connect to my site using another computer and the browser sends a cookie that corresponds to somebody else, you will be mistaken for that other person and, when leaving, a cookie corresponding to you might be left on that computer causing that other person to be mistaken for you later on.

If that deal is expressed up front, I guess most users would accept it. Those strongly opposed to cookies should find it acceptable to login each time they connect to the site.

What is the feeling of PHP developers on this user interface issue?
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

A. Accept my cookies and you will be saved mangled URLs that are inappropriate for bookmarking.
True/required point.
B. Trust that my cookies are not an invasion of your privacy.
Again, true/required point. Biggest flaw with cookie based systems. However if you're project is Open Source, most people who are paranoid about privacy can check for themselves how the cookie is being used. Most paranoid privacy folks are willing to do this it seems....

C. Be aware that if my server receives no cookie from your browser to identify you (so my pages can be adjusted to your preferences), you will need to identify yourself by entering your username and password.
I think I know what you're saying here, but I'm afraid others might get confused. I think you mean "If a server doesn't receive a cookie from the client in the first page view with a given session, the client with have to authenticate." I think some users may think you're implying the have to authenticate on every page view if no cookie, which would be horrendous.

Are you considering using persistent or transient cookies? Transient cookies are set with a time_to_life = 0 and are deleted when the browser closes, but can last indefinitely if the browser is left open. If using persistent cookies, the cookie is saved on the clients computer for future visits. From a privacy perspective, transient cookies are much better and much less likely to be stolen due to XSS attacks. So this means you don't have a "remember me" type feature, but people only need to log in once per "session". Your point 'A' above suggests that if they don't accept the cookie they have to live with URL mangling, so again, they'd still only have to log-in once per session. (I wasn't sure if you were thinking that the user would have to log in on every page view if no cookie. That would definately be a bad thing, and if you thought that I can see why you would object to it.

Alternatively, if you check out the mini-howto I linked earlier I show how to setup a short duration, self renewing cookie. Ie set a cookie good for say 10 minutes from the last page view. Use application logic to deny expired cookies -- the howto protects the expiration time from tampering. You'll have to select the expiration time based on the expected user-interaction with your site. If its bursty a 5-10 minute window should be fine, if its more low-key but throughout the day, maybe a 1-2 hour renewel is appropriate. In these case closing/reopening the browser within that window will preserve the session.
D. If somebody else uses your computer to connect to my site, the browser will send a cookie causing that person to be mistaken for you.

E. If you connect to my site using another computer and the browser sends a cookie that corresponds to somebody else, you will be mistaken for that other person and, when leaving, a cookie corresponding to you might be left on that computer causing that other person to be mistaken for you later on.
See the discussion above regrading transient cookies. If you use them, and the browser is closed after the client finishes, no one can simply hijack the cookie, even on the same computer. Likewise if you use a short duration permement cookie, its unlikely to have this type of hijack. The default cookie used by PHP for its default sessions is a transient cookie -- it doesn't last past a browser session.
If that deal is expressed up front, I guess most users would accept it. Those strongly opposed to cookies should find it acceptable to login each time they connect to the site.
Yeah I was anti-cookie about two years ago. Then I went though a very similar post based approach (which made my broken back button problem worse) and <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> off some users. I then took the default session path, made a lot of people happy. Had to do some minor tweaking to get name mangling working for my two vocal anti-cookie users (older 4.0.x releases didn't propagate some places they should have, still don't recognize local redirects). Shortly both anti-cookie users offered to help out a little with some coding, realized the challenge of cookieless sessions and decided cookies were OK by them, at least from me.....
What is the feeling of PHP developers on this user interface issue?
You already know my stance :)
mgelinas
Forum Newbie
Posts: 13
Joined: Tue Jun 10, 2003 6:33 am
Location: QC Canada

Post by mgelinas »

Thanks Eric for your enlightening post.

Rasmus Lerdorf, co-authoring Programming PHP (O'Reilly, 2002), wrote at page 184:
By default, the session ID is passed from page to page in the PHPSESSID cookie. However, PHP's session system supports two alternatives: form fields and URLs. Passing the session ID via hidden fields is extremely awkward, as it forces you to make every link between pages be a form's submit button. We will not discuss this method further here.
When I read the book, I had wished Rasmus would have discussed the method further. To make it worse, Rasmus started the next paragraph with:
The URL system for passing around the session ID, however, is very elegant.
You came to the rescue of Rasmus very elegantly. Thanks a lot.
Post Reply