PHP web application security [closed]

Question

I am building a PHP web application, that needs enhanced security, due to the fact that it contains very sensitive information (in a database).

I think that I want to use self-signed SSL certificates that will correspond to each user and store them one level above the web root folder (for simplicity's sake /var/www/certs where the root is /var/www/domain1.com). I would disagree on the option to store the key and IV in the database due to the fact that if an attacker obtains a copy of the database he has the keys for all doors, which makes the encryption useless IMO. That is the reason why I am considering using the p12 certificates, only as a key and vector storage.

Are there any chances that an attacker who gains access to the application, by exploit or any other method, would be able to get access to the certs if they did not previously know about them? (The scenario is if an attacker exploits vulnerability in the application itself, not in the server, to get access to a files that he is not aware of)

Answer 1

If an attacker has access only to the "live" database (most commonly via SQL injection), then encrypting the fields using some secret not stored in the database is enough - even some hard-coded secret key in the application code or configuration file. There's no need to use per-client keys.

If you're worried an attacker could somehow access the data at your web root, but not the rest of the filesystem (common if your server is misconfigured to allow browsing its web root contents), nothing changes - afterall, your server code or configuration file should be outside the web root, right? (I have little experience with PHP, so I might be wrong about this)

If your concern is an attacker getting hold of the whole filesystem, then you should ensure the key only exists in RAM. One way of doing that would be requiring a password to be entered at server (re)start, and keeping the derived key in a globally accessed variable (again, I dunno if it's possible with PHP). There might be other options, but any I can think of would introduce other points of failure.[1]

I was thinking of generating the certificates on registration and use part of the footprint of a certificate to encrypt the user's data. so the SHA1 or MD5 footprint could do as key and IV.

Using anything from the certificate is a bad idea, since certificates are by definition public (the private parts never leave the user machine). If you could somehow have the user decrypt some data using his private key (something that AFAIK is not widely supported right now, but could be in the future), client-side, then you might be up to something... But the way things are now, you could simply create a random key for each user and have your application code read it (from a secure place) and apply it to the user data before inputting/outputting it.

This, of course, assumes you need to isolate one user's data from the other users. If that's not the case, a single global key might suffice, as described in the first part of this answer.

(one last note: you haven't mentioned the method you plan to use to encrypt data. If you're using a stream cipher, for instance, having a single IV for each user is not enough - you need to have a different one for each datum you want to protect. It doesn't matter though how you store them, since they're not supposed to be confidential, just unique. There are ways to make a single IV useable for encrypting a lot of data, but that's beyond my current knowledge, so I won't opinate on them.)

---

[1]: Just to name one, you could derive an encryption key from the user password, store it in a (secure) session cookie, and pass it back-and-forth from server to client. Since it's not stored anywhere, an attacker won't gain access to it even if he got hold of the whole server (assuming of course your site properly salts and hashes passwords and the authentication key and encryption key are independent of each other). For some defense-in-depth, you could even combine that key with one stored only in the server. The obvious downside is that part of your system security now depends on the user browser, and also the way session cookies are handled both in the server and the client.

Answer 2

You seem to have a fundamental misunderstanding about writing secure software and probably shouldn't attempt to roll your own with your current level of understanding. SSL certificates won't do you any good at all for protecting DB access or the contents of the DB. Not only would people almost certainly be able to get to the certs, but it does nothing to protect you.

To protect a DB, you need to filter input to prevent SQL injection, harden the server itself and if necessary to protect the data at rest, use encryption, which only requires keys that can be encrypted with password derived keys and stored in the database itself.

Answer 3

Are there any chances that an attacker who gains access to the application, by exploit or any other method, would be able to get access to the certs if they did not previously know about them?

Yes, it is not only possible, it is likely. Any file that your application has access to, anyone who takes over you application will also have access to. Typically he'll be able to view directory listings, execute programs, and do anything a normal user could do.