PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

Storing Session Data In Cookies: Problems And Security Concerns To Be Aware Of

Note: This article was originally published at Planet PHP on 24 January 2012.
Planet PHP


Image via Wikipedia

Back from my extended leave of absence, I'll re-open the dusty cobwebbed depths of this blog to echo the sentiments of Paul Reinheimer in his recent article aoCookies don't replace Sessionsao. The topic is actually an old one since Ruby On Rails has adopted the strategy of storing application session data in cookies by default (take note, performance hounds). The purposes of storing sessions in userland cookies rather than the conventional aostick-it-on-the-filesystem/databasea used by many apps is one of performance and a little obscuration. Cookie data can be accessed faster than hitting the filesystem/database plus it has the dubious ability to disguise the session-targeted programming language. Really though, PHP is assumed to be on all web servers so hiding its existence is a bit like trying to hide an elephant in a zoo. Hide it all you want - we still know there has to be one in there!

In exchange for speeding up session reading, storing session data in cookies has some fairly uncomfortable costs.

Now, developers are not unaware of the problems of storing potentially sensitive application data in plain text files on the user's PC which users can manipulate, copy, and mangle to their (or the hacker's currently fiddling with the user's PC) heart's content. It's dangerous depending on just how much you rely on session data to drive other security rules or restrictions on business logic within the application. Technically, the reliance placed on sessions should be close to nothing - session data should drive the application towards other storage solutions for the really essential stuff and just stay around as a minimal identifier/stash of basic ID info. Such minimal information can be dumped, corrupted, or overwritten with the only cost being to perhaps require a user to login again when that happens. Stuffing a bank balance into a session, on the other hand, is one (very exaggerated!) example of the kind of data you should be shot for relying on a session for.

Programmers being programmers, it's not rare to see sessions become a more intrinsically important storage location than it should be. In those cases, being able to manipulate the session data can become a problem and may give rise to exploitation scenarios where tampering with the stored data leads to some benefit for the manipulator. Obviously we want to make sure that that can't happen even in scenarios where programmers may be a bit loose with where they store data. We don't build frameworks and libraries for Gurus, we build them for all programmers - even the sometimes ignorant and under trained ones. This cookie stored session data is often coupled with the ability to encrypt that data. Howevera

As Paul Rainheimer remarks in his article, aoEncryption is often viewed as a panacea for security problems, you sprinkle a little encryption dust around, and your problems dissolvea. This is an absolute truth in programming - programmers often view encryption as a solution without regard for one teeny tiny problem. If you encrypt a set of data for any purpose, even though it's encrypted, the user (or the hacker hacking the user's account) still has the data in some usable form!

With perfectly intact data, and even through it's hidden by encryption, that data can be recycled simply by copying it to another machine. Depending on the data that is stored (which admittedly may require the hacker/user to figure out by doing actual work like finding your open source a

Truncated by Planet PHP, read more at the original (another 3726 bytes)