Setting up PHP Sessions?

Filed under:  Google about "PHP"

While using the net, you may have seen web sites that require your browser to support cookies. The reason why, in my opinion, is simple. Such a requirement is another layer in the battery of security measures available to webmasters. This one is aimed to minimize the possibilities of session related attacks. It is just a reasonable "restriction" at a minimal cost when critical transactions are involved. Probably, all potential users of such interaction have browsers with cookie capabilities. It's a matter of balance.

If you run a web application that relies on PHP sessions, why not do the same online banks or ecommerce sites do? Ah... what would you loose? What would you win? Well, obviously I'm for doing so. Here, I'll try to point non-developers to some information to help them decide. Then I propose (and describe how) to require cookies for session's tracking while taking advantage of browser security features to protect those cookies (on the client side) and also make sure PHP will never append the SID to URLs.

At this point, you may wish to take a look at the PHP manual itself. However, even if you're a web developer, you'll notice there is a lot of stuff in there, specially in the user comments (a great resource, by the way). Also, there are some functions kept for compatibility reasons. In the end, you may feel lost, but... who said computers were easy?

Besides dealing with PHP sessions, there are other security related measures that you could (or should) consider, but this is outside of the scope of what I would like to cover here. The rest of this document is organized into small sections, that depending on your background, you may wish to skip. Still I hope you may find something useful, good enough if it just makes you thing a bit about it.

  • PHP Sessions?

    Web applications track user sessions by means of the so called session id (SID). PHP session support [1] allows programs to register arbitrary numbers of variables to be preserved across requests. When a visitor accesses a site, PHP checks whether a specific SID has been sent with the request. If this is the case, the prior saved environment is recreated. Session tracking is great for user authentication, ecommerce, etc.

  • How do I know if my web application uses PHP sessions?

    It should be noted that not all applications use PHP based sessions. For instance, phpBB uses its own layer for session management [2].

    As far as I can tell, that doesn't seem to be the most common practice. In fact, many web applications such as content management systems (f.e. Drupal) and others rely on PHP sessions, but of all them probably have a particular sign in common that you could recognise. Something that you could easily find, such as calls to functions provided by PHP to manipulate sessions, or notes about requirements related to PHP settings. If you're not sure, you may try to scan the documentation or the source code for session_start, session_register or session.auto_start.

    There might be cases where the relevant PHP settings are encapsulated behind application parameters, so you don't have to deal with them, directly. Still, if you know the "inners", that may help you figure out how to better tweak those options. If in doubt, the developers themselves will probably guide you in the right direction.

  • Security issues?

    There is a source of concern with PHP sessions though, that you should be aware of. If a malicious user is able to obtain the SID of another user, they could impersonate that user and get access to critical information and/or functionality.

    Not sure with other programming languages, but with PHP there is an additional problem. PHP doesn't check if a SID is valid or whether it exists, it simply trusts anything that the browsers sends. Hence, user impresonation may also happen if a malicious user is able to make another user follow a link with an arbitrary SID. The attacker would not have to obtain the SID because it is already know to them.

    Both issues are known as session hijacking and session fixation. The hard part to prevent this kind of attacks is on the developers side (see references below), but there is still something that relies on the one who installs the application.

  • References:

    In fact, there is a lot of literature about session fixation/hijacking out there. However, most of that information is targeted to web developers. Here, I've tried to collect the most relevant pointers on the subject.

    1. PHP session handling functions
    2. phpBB sessions
    3. Open web application security project guide
    4. session_fixation.pdf (www.acros.si)
    5. PHP and Session Fixation (hardened-php)
    6. PHPsec.org Security Guide considered harmful (hardened-php)
    7. PHPsec.org Security Guide: Sessions
    8. Cross Site Scripting (XSS) FAQ
    9. ha.ckers' XSS cheat sheet
  • PHP Sessions may depend on you

    Regardless of the web application that you use, when it comes to session identifiers, its behaviour may depend on how you customize some PHP settings.