on 31/05/03 1:26 AM, George Whiffen ([EMAIL PROTECTED]) wrote:
> 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. Maybe I'm missing something, but generally speaking, session id's are transmitted in plain text via either the URL, or via a cookie (neither of which is usually under SSL) so I don't see why you're paying so much attention to "cracking" or "hijacking" session ids... it is, to my knowledge, really easy to find out someone's session id, and similarly easy to hijack it. What's the option other than storing a value like "logged in"??? Storing the uid and pwd on the client side is a no-no, and storing them in the session in no more secure that storing "logged in" since the session can be hijacked. My preference is to re-ask the user for a password before: a) changing a password b) doing anything secure (like changing passwords, transferring funds, altering private information, etc etc) which is the ONLY reinforcement that is secure (ask them, then ask them again later). I don't really get your point. Yes, sessions can be unsecure, but so can $_GET variables in the wrong hands. > 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. As long as an user-supplied data is appropriately validated before storing in sessions, I cannot see a way for the user to harm the session data, or to store bad data. Isn't the the whole point of storing JUST a session ID on the client machine (either in URL or cookie) and the data server-side, rather than storing all data client-side???? If a user indicates a preference for a blue background, and I validate the data that states this (sent to the script via POST or GET) before storing it as a session var, then I can't see where the danger lies... only PHP scripts have access to session data, and only a validated, expected data should be added to the session. > 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. Huh? A session ID is a value passed around in the URL or via a cookie to maintain state. That is, separate scripts on a server can recognise and differentiate two different browsers/sessions/users. Assigning server-side session variables to that session ID means that from one request to another, a php script can determine what's been done in the past... this might be something insignificant, like remembering a colour preference, or it might be remembering a number of items that the user wishes to purchase. All this is done via http (page requests and passing the session id around), with the data stored server side in a flat file, or in memory, or yes, even in an SQL database. How else would you propose my script remember your shopping list other than: - cookies (laughable) - extremely long URLs and hidden POST variables - asking you to write it down on a piece of paper and remind my script later Regardless of whether you feel the internet should have state, or should not is pointless... the fact is, there are internet applications which require state... If it is possible to maintain state (with, for example, a session id which identifies the browser/user, and relates this back to data stored server side) via http, then I would say that the internet *CAN* have state. > 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. A session is no more than recognising a browser/user/session via a http request, and relating it to information stored on the server (files, memory, databases), giving a form of state. The only danger lies in people hijacking session ids. > 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? I think the key point you're missing is that a session id is just a way of differentiating between two users/browsers/sesssions. Rather than passing multitudes of data around in a URL (easy to spoof), Cookie (easy to spoof) or POST variable (also easy to spoof) and letting anyone fiddle with it, all we do is pass around a unique identifier, which relates this session back to data stored on the server in a file, memory or a database. Rather than constantly having to revalidate and check user-supplied data from URLs and cookies, you check it once, then assign it to the session. I'm not sure what you'd use sessions for, but me, I like to remember if a user is logged in, what their preferences are for language and dates and the like, what items they want to buy, etc etc... passing a value like "logged in" around in a URL, cookie or POST var page after page after page is just ludicrous... more than anything else, it gives the user opportunity to alter the value (requiring another check, and opening up security holes the size of the grand canyon). I'd recommend you actually create a small app which uses sessions, and get to know them, THEN come up with a list of complaints... it's nothing more than http requests, GET variables (or cookies), and server-stored data all related to each other. Coupled with a smart programmer who knows how to check/validate data, I haven't seen any flaws in PHPs implementation of sessions. You are aware that you could write your own session handling code? You are also aware that every major shopping site (let's start with the obvious, amazon.com) uses state to remember what you want to buy??? Some sites do it client-side (cookies -- shudder) and others do it server-side with an identifier passed around in the URL or a cookie (commonly referred to as sessions). It's late, so I hope I'm being clear, and giving you the information you need. Justin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
