There aren't a whole lot of shared servers that are running a different pool of httpd for each user, nor using only CGI with different user ids, nor...
I daresay that unless you are setting up a shared server yourself, rather than renting space on one, you'll be hard-pressed to find that feature...
Perhaps phpsec.org would want to list hosts who go above and beyond the current norm and actually provide that.
That's not a bad idea, but I'm not sure such endorsement would be beneficial, since it crosses into the territory of business interests. On the other hand, hosts might see huge value in being endorsed by the PHPSC and make a special effort to comply with recommendations and such.
I guess a good first step would be to generate a document that details some options for running a secure shared host, so that people can apply the practices that fit their needs.
If you're stuck on a shared host with poor security, your best hope is to keep all sensitive data (session data included) in the database, relying on its access control for some protection. This places all of the trust in your database access credentials, and there are some pretty effective ways to keep this information protected. You can at least keep people from browsing around with scripts like this:
http://shiflett.org/code/browse.phps
If you can think of a good business reason to store somebody's CC# in $_SESSION, I guess it must exist.
I sure can't think of one...
When a user enters a credit card number, there may likely be a verification step before the actual purchase is made. It's better to keep this number on the server (in the session data store) than to unnecessarily expose it over the Internet again (SSL mitigates the risk, but an unnecessary risk is still worth avoiding).
Being mindful of this, it's also helpful to not even display it to the user, instead showing only the last four digits or something, because this display also counts as exposure (since it's in the response).
I'm certainly interested to know when/why Chris Shiflett would store a CC# anywhere at all, unless he's actually working *FOR* the Credit Card guys, cuz that's what they're there for. :-) That doesn't count.
Heh. :-)
You might need to store credit card numbers if you're someone like Amazon and you see a great deal of value in making future purchases as convenient as possible. Whether it's one-click ordering or not, statistics prove that customers are more likely to buy products when the purchase barrier is reduced. Sure, this is necessarily going to be less secure than destroying the credit card number after each use, but there are ways to mitigate the risk, and security can't always take precedence.
I'm doing some security consulting for an Amazon-like company right now that requires this. The credit card numbers are all encrypted and kept in a secure database (my opinion), and I've added specific safeguards to protect the symmetric key from theoretical risks (for example, Apache has insufficient privileges to access the key, so even command injection can't necessarily be used to obtain it).
Of course, this is all tangential to the whole password in a cookie discussion, in which case I'm not aware of any situation or business need that can possibly justify that. :-)
Chris
-- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
