Some great points in here George - but it leaves me hanging.... What are the options? If we are not to use a 'state-ful' system, how do you track users preferences, login/logout states, shopping baskets, and other items that need sessions or some other type of reliable tracking method?
Not that I am saying sessions are 100% reliaable - they are as good only as the cookie that is returned, and that is not 100% reliable - but it is the most reliable method that I am aware of - unless I am missing something :) So all that you say may be true, but what are the options? On 5/30/03 10:26 AM, "George Whiffen" <[EMAIL PROTECTED]> wrote: > Dear All, > > There doesn't seem to be much discussion of the disadvantages and long > term dangers of using php "sessions". So let's redress the balance: > > 1. Heterogeneous Code Environments > php session data is not easily accessible from non-php code e.g. > Perl/C/ASP etc. In contrast, either client-stored data e.g. cookies, > hidden posts, get variables, or data stored in a structured database > table, (i.e. one column per variable), is easily accessible from other > code. > > The implication is that sessions may suit you fine as long as only php > is used on your site. However, if your site matures and you ever want > or need to use another language for some pages, it will be hard for > those pages to access data stored in sessions. On the other hand, if > the data had been stored in an well-established industry standard > format, you should have no problems. > > 2. Provably Secure Authentication Data > > Hopefully we all know by now that the best way to safely authenticate > for access control is to make sure the username/password is checked > every time either by your script, your webserver or a trusted third-party. > > However, I have the feeling some session users are tempted to simply > authenticate in one script and store a "logged in" or username flag in > the session without the username/password having been re-validated. > > It's not a complete disaster if you do this, which probably means lots > of people do it! But this is only as secure as the session_id key. I > don't doubt that session_ids are generated with a high-quality random > number generator and should be suitably uncrackable. > > However, the crackability/vulnerability of a username/password schema is > very well understood. Can we really say that the > vulnerability/crackability of a session_id is as well understood? > > What happens if, and I'm sure it's a remote chance, there is ever a bug > in the session-key generation that stops them being so random so a > "session_id" crack becomes not just possible but real easy! > > Usernames/passwords just don't have that kind of vulnerability, and the > vulnerabilities they do have are well known. > > 3. Independent Audit of Server Stored Data > > Procedures for independently verifying the data stored on a server in a > SQL RDBMs are well established. It is easy to query the database schema > to see what columns are defined. It is easy to verify that the data > actually held in a column is as expected. In general it is easy to > prove and verify what data is held e.g. to prove Data Protection > compliance or Bank/Credit Card requirements, (no storage of cvv2 for > example). > > It is intrinsically much harder to prove that the contents of php > session data are compliant. You need to write a php script to unpack > the session data. That means proving that that script itself is safe. > Even after you've unpacked the session data, you still have to make > sense of it. Different sessions may hold different numbers of > differently named variables. But that's not all, the same variable may > hold data in different formats in different sessions! > > Practically you have some pretty complex processes to prove what data > you have stored and to verify that you have stored what you thought > you'd stored! > > All in all, php sessions are NOT going to be popular with data auditors. > Once again, that may not matter to you now, but down the line it could > become a BIG issue. > > 4. State-ful Designs > > My personal concern about sessions, is more about the design issues. > What worries me is that sessions may be used to try and re-create > client/server style "state" when the most distinctive advantage of the > internet, (and the key to its astounding success), is that it is > fundamentally state-less. > > What this means, is that the internet is based on the principle that > every request is entirely self-contained and independent of any other > request. There is for example, absolutely and explicitly, no guarantee > that http requests will be received in chronological order. It is all > strictly about "best effort", and no guarantees. This is why the > internet works: each component does its own job as well as it can > without worrying about what else is happening. > > The implication from a design point of view is that you should not be > making any assumptions about what has "gone before" or what "will come > after" your php script runs. The functionality offered, should, as far > as possible, be completely self-contained, with each php script acting > as a "component" in its own right. That means no direct interaction > between the scripts. Interaction should be gated through third-party > standard interfaces such as http or SQL. > > The problem with sessions is that they encourage you to break this model > by creating a new set of "super-global" data holding "state" > information. This data is not exchanged through established standards, > but rather, "floats around" in the background, changing the behaviour of > the script but without being clearly externally defined. > > If the session data is only concerned with "cosmetic" data such as user > style and colour preferences, this doesn't particularly matter. But if > it holds important or critical data, it does matter. Each script is no > longer a well-defined self-contained component, but more or less > intimately bound up with other scripts that share the same session. > > It's worth remembering that there is nothing remotely new about > "state-ful" design. VDUs connected to mainframes are about as state-ful > as you can get. Indeed, the single distinctive feature of the two most > successful software technologies of all time, (the internet and SQL), is > that, (unlike their predecessors), they are both fundamentally > state-less protocols. > > > 5. Reduced Component Reusability > > A practical example of the problems of this style of "state-ful" code is > in reduced reusability of the components, (php scripts in this case). > One of the great benefits of the internet's stateless approach is the > tremendous ease with which uri-addressable components can be reused. > For example, a single graphic can be very easily used on any web page, > anywhere, anytime, with no additional effort than making it available on > one web page on one site, once. > > Similarily, php scripts which are properly structured components, (e.g. > no significant session data use), can be reused, without code change for > many different purposes. If session data is used, e.g. to pass search > criteria or results data between pages, this flexibility is > significantly reduced. > > For example, it's very handy when maintaining data in one table, to be > able to offer direct links to updates of related data. But if the update > form for the related data is coded to expect the details of what it must > update from session data e.g. to have been set from a search/list/select > page, this won't work. So, just because you used sessions, you, (or > someone else), may not be able to offer direct links, (or bookmarks), to > the update page even when the appropriate database keys are already > known. You either have to force the user to duplicate effort by > unnecessary traversing of a new search/list/select or you have to write > new code to handle this new type of request. > > On the other hand if the update is coded as a proper component i.e. it > reads the key of the data to be updated from the http request, (GET, > POST or COOKIE), then you can automatically allow it to be accessed from > anywhere without having to always go through some particular > search/list/select sequence. > > This is one, among many possible, examples of how, by establishing a > hidden, private, relationship between php scripts, session data > automatically and inevitably reduces the accessibility of the > functionality of the script. > > There is a direct parallel in "lower-level" code structures. Over use > of session data is as intrinsically hostile to code re-use as over use > of global data to communicate between distinct functions or objects. > Just as functions and objects should use the "public" interface to > exchange data i.e. arguments/methods/properties, so php scripts should > exchange data via "public" interfaces i.e. http requests, databases etc. > > > > Well, I've convinced myself. Of course, as I don't use sessions I may > have missed something, (or everything). So, please, what have I got wrong? > > > > George > -- Cheers Mike Morton **************************************************** * * Tel: 905-465-1263 * Email: [EMAIL PROTECTED] * **************************************************** "Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple." - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
