|
|
Posted by Chris Shiflett on 10/19/46 11:13
Richard Lynch wrote:
> 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/
Navigation:
[Reply to this message]
|