Hello all,

This is my first topic .. Please Help me 🙂

The question is:
I Have a website and I am using PHP 🙂 The employees use my website to upload their documents (PDF files). These files will be stored in the server.

Now how can I protect the PDF files in the server from developers ? I don't want developers (even me) to open the files from the server if they want to see the files they can login into the system and see the files (if they have the permission).

I want when I click on the file (in the folder) I can't open it!

Do you think serialization (object) will solve this problem?

Is there a technique similar to encryption can solve my problem?

Thanks in advance.

    You could make the folder only readable by apache (or whatever your web server "user" is), while making sure it's outside of the document root directory tree. However, anyone who knows the apache password or has root access could still read it.

    To truly lock them down, you may well have to go with encryption. I'm not sure at this point how I'd handle the keys, though, since you'd probably want them in the DB rather than requiring a user to submit their private key each time they want to view a file. Hmm...have to think about this some more....

      NogDog;11053195 wrote:

      You could make the folder only readable by apache (or whatever your web server "user" is), while making sure it's outside of the document root directory tree. However, anyone who knows the apache password or has root access could still read it.

      To truly lock them down, you may well have to go with encryption. I'm not sure at this point how I'd handle the keys, though, since you'd probably want them in the DB rather than requiring a user to submit their private key each time they want to view a file. Hmm...have to think about this some more....

      Thank you NogDog for the prompt reply.

      We can encrypt the keys?

        reemcs wrote:

        Now how can I protect the PDF files in the server from developers ? I don't want developers (even me) to open the files from the server if they want to see the files they can login into the system and see the files (if they have the permission).

        The problem is that there has to be someone who can acquire root access in order to do the admin work required, and that person can therefore access such files, bypassing server-level security.

        NogDog's suggestion of encrypting the files such that the authorised user submits the secret key (over a secure channel, i.e., using SSL/TLS) is secure, at least unless the server administrator is able to install a backdoor to feed him/her the secret keys that were submitted. Furthermore, it is inconvenient. NogDog's musing about placing the secret keys in a database would be more convenient, but in order for the secret keys to be used, the code must have access to the database, hence the server administrator will have access to the secret keys.

        I guess you could have two server administrators, and then require them to manage the server together. This way, they would have to collude, which reduces the chance of a rogue server admin being successful. I don't know how you would enforce this in practice though... somehow they each share half of the SSH private key? lol. It is even worse if every developer has admin access to the production server, but a normal staging setup with only a select few trusted with access to the separate production server should be a sane way out.

        For reducing the chance of a backdoor from being installed in code, code reviews should be done, but of course while this could stop a rogue developer (unless they collude, but then with version control you have evidence that could be used to fire them and maybe even take legal action), it does nothing to save you from a rogue server admin.

        Maybe the easiest way would be to institute a policy of client-level encryption, i.e., everyone encrypts their files before uploading. On the other hand, IT personnel with TeamViewer access could spy on them...

          10 days later

          To paraphrase laserlight and NogDog, if the server encrypts the files, then anyone with access to the server may be able to discover the process whereby they get encrypted and reverse this process. For example, a developer could login to the server, read the PHP source code that handles the file uploads and encrypts the documents, and then see how the encryption is performed and what keys are used. Any program that encrypts the files would have to have access to the keys that encrypt the files. If you want to exclude your developers from decrypting the files (or accessing them before they are encrypted) then you must deny your developers any way to access the keys.

          I have seen configurations where a server can only encrypt files using a public key and does not possess the private key to decrypt the files. E.g., files are uploaded to a server, the server uses my public key to encrypt the files and emails them to me and only I can decrypt them with my private key. You might consider something like this IF your users can decrypt the files locally (like on their laptop or workstation using some program) OR if you can run some kind of second machine -- that your developers cannot access -- which can decrypt the files and which also has some means to authenticate users to determine who deserves access to which file.

          There are possibly more subtle shades of options as mentioned by NogDog and laserlight. Security like this is a pretty complex problem sometimes because you have to consider every step in the custody chain of your data. Ideally, each user would encrypt their own files before the files are delivered to the server, but this would require each user to run some kind of software on their respective machines. I was thinking you might be able to pull off encryption using Javascript (see https://code.google.com/archive/p/crypto-js/ ) but I don't think your browser is allowed to access the contents of your file system because this presents a security risk.

            Write a Reply...