Re: [PHP] Sessions can be dangerous
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
RE: [PHP] Sessions can be dangerous
George, Having created an invoicing system using php , I very clearly understand the advantage the session construction holds : the information is maintained on the server, rather than floating around in cyberspace between the client and server each and every time you exchange information. If you want to use hidden input you need to set up a secure link each and every time you transfer the o so important username/password combination. Furthermore , the session data is not that difficult to access with another program as long as you can capture the session-id, which you can. All in all , I did not yet come across a better system to get something working in a manageable and secure way. You could go a step further and mimick the session_data management via a database interface if your data quality is such an important issue, but then again, make sure you have a foolproof system to make logging in into the database secure ! Nobody forces you to use the session system and if you want to shy away from it , it is your choice, but I am a little bit afraid that your lenghty email about session insecurity will be meaningfull only for the core PHP developers/auditors. Wim -Oorspronkelijk bericht- Van: George Whiffen [mailto:[EMAIL PROTECTED] Verzonden: Friday, May 30, 2003 4:27 PM Aan: [EMAIL PROTECTED] Onderwerp: [PHP] Sessions can be dangerous 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
Re: [PHP] Sessions can be dangerous
Wim While I do see the usefullness of sessions, I have to disagree with you on the security aspect. A session ID is just as vulnerable to sniffing as is a username / password combination. The only security you gain from using it instead is that it's value is time limited. If your application reallys needs all that security, you'd better be using a secure transport, period. The session might even be worse, because, for instance, if you're using the files session handler, another user of your system may be able to easily read the current sessions id's from the temp folder, and hijack an authenticated session, even if it were encrypted. As george stated, there is also always the chance that the session_id generator is NOT secure, in which case you're really up the proverbial creek. You're right, however, in that storing all the state information on the server is a good thing. Why pollute your html with hidden fields, or mangle the heck out of your urls. I DO believe that maintaining state is a necessity when attempting to write Applications on the web, instead of just web pages. --erik Wim Paulussen wrote: George, Having created an invoicing system using php , I very clearly understand the advantage the session construction holds : the information is maintained on the server, rather than floating around in cyberspace between the client and server each and every time you exchange information. If you want to use hidden input you need to set up a secure link each and every time you transfer the o so important username/password combination. Furthermore , the session data is not that difficult to access with another program as long as you can capture the session-id, which you can. All in all , I did not yet come across a better system to get something working in a manageable and secure way. You could go a step further and mimick the session_data management via a database interface if your data quality is such an important issue, but then again, make sure you have a foolproof system to make logging in into the database secure ! Nobody forces you to use the session system and if you want to shy away from it , it is your choice, but I am a little bit afraid that your lenghty email about session insecurity will be meaningfull only for the core PHP developers/auditors. Wim -Oorspronkelijk bericht- Van: George Whiffen [mailto:[EMAIL PROTECTED] Verzonden: Friday, May 30, 2003 4:27 PM Aan: [EMAIL PROTECTED] Onderwerp: [PHP] Sessions can be dangerous 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
Re: [PHP] Sessions can be dangerous
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
Re: [PHP] Sessions can be dangerous
On Fri, 30 May 2003, George Whiffen 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. For anything beyond a trivial application, you are going to be writing your own backend save_handler anyway, so I don't really see how this is an issue. If you don't want to write your own save_handler (which is really really easy) you can always just set session.serialize_handler = wddx in your php.ini file and you will have the data stored in a standard XML format instead. This format is very accessible from non-PHP code. 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. Sure, but this isn't really specific to sessions. I would say this is related to any cookie a developer might create. There is always the temptation to not include the auth headers on each page and just toss the logged in user id into the cookie. This is obviously a bad idea, but I wouldn't necessarily attribute this to an inherent danger in sessions. 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! Again, see point 1. Any real usage of sessions is going to need a custom save_handler most likely written against a real database. You simply cannot go beyond a trivial single-server web-app without doing so and the facilities in the php session support for doing this is good. 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 boat has long since sailed on this one. People need and want to maintain state. You can't build any sort of shopping-cart style site without them. 5. Reduced Component Reusability ... 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. I tend to distinguish between the human interface to an app and the machine interface. Trying to put them both into the same interface tends to make them cumbersome for both sides. Often the human interface is just a thin layer on top of an underlying machine interface and it is at the machine interface that you have your reusability and transparency. In a properly designed architecture, the session layer is simply part of the human interface and really doesn't affect the reusability of your base machine interface. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
