6

I continually hear and read people warning against the perils of placing proprietary information or confidential documents within the web server root directory. If I am on a shared server, I cannot place files "above" the root in the document tree. Is there a work around for this that is not too hackish?

More specifically, I would like to put configuration information into an ini file. What can I do that so people cannot download it (let alone modify it)? Where should I put it to minimize the risk of misconfiguration or bug exploitation?

Improve this question
5
  • What is your webserver, can you configure it, to what extent?
    – Thomas Orozco
    Sep 12, 2012 at 21:48
  • 1
    There are some control panels out there (plesk, among others) that force users on a shared hosts to only read from their own webroot, instead of jailing them to their own home directory. This always bothered me.
    – Jacco
    Sep 13, 2012 at 5:42
  • Just encrypt the files before you upload them. I don't trust shared web servers to be honest.
    – Ramhound
    Sep 13, 2012 at 11:22
  • I have access to an ini file not on the webroot. I was thinking of storing my configuration info in there for logging into the DB.
    – nodirtyrockstar
    Sep 13, 2012 at 15:19
  • 1
    @Ramhound I doubt encrypting the files before upload would help since they are presumably there to be read by the application, so the code to decrypt the file would be sitting right next to it.
    – Michael Mior
    Sep 13, 2012 at 15:20

2 Answers 2

Reset to default
2

If it's that important, there's not much you can do. Any steps you take can easily be thwarted by a misconfigured server. If the file must be within the Web root, then your only option is to use whatever mechanism your server allows to disable access to these files (e.g. .htaccess for Apache).

Improve this answer
10
  • As I thought. So creating an ini file would be too dangerous, I suspect...
    – nodirtyrockstar
    Sep 13, 2012 at 15:18
  • @nodirtyrockstar Probably. If security is that important for this project, it's worth spending extra for some type of VPS.
    – Michael Mior
    Sep 13, 2012 at 15:19
  • It isn't critical. I am developing a site for a small record label. All financial transactions will occur on a third party site, so my client's site will only contain a couple of blogs, a product catalog -hence the need for the DB- and some other minor stuff that is not necessarily proprietary.
    – nodirtyrockstar
    Sep 13, 2012 at 15:21
  • I mainly want to guard against XSS and injection, but since I don't know what the future holds, I just want to set them up to be as secure as possible.
    – nodirtyrockstar
    Sep 13, 2012 at 15:21
  • 2
    @nodirtyrockstar Then you're probably safe since the info you're protecting is public anyway (with the exception of password hashes). You may be able to ask your host to set the file permissions so the Web server can't read the file. Your biggest risk is probably not data theft, but someone messing with the DB. So just make sure you have regular backups.
    – Michael Mior
    Sep 13, 2012 at 15:23
0

Define "shared"- how are user permissions handled?

You're safe-ISH if your SSH user is the only one that can see the file- if the permissions are 400 (only permission is read by your SSH user), but this isn't particularly useful if the "private" file needs to be accessible by apache2/the www-data user.

You could do this relatively cleanly depending on your use case, and if your sysadmin will do you a favor and manually edit file permissions on your files.

What is the umask for the system, and how are you getting files onto it?

Unfortunately, with shared servers, the answer is usually: depends, depends, depends.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .