Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
What is your webserver, can you configure it, to what extent? –  Thomas Orozco Sep 12 '12 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 '12 at 5:42
    
Just encrypt the files before you upload them. I don't trust shared web servers to be honest. –  Ramhound Sep 13 '12 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 '12 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 '12 at 15:20
add comment

migrated from stackoverflow.com Sep 12 '12 at 22:49

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 2 down vote accepted

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).

share|improve this answer
    
As I thought. So creating an ini file would be too dangerous, I suspect... –  nodirtyrockstar Sep 13 '12 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 '12 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 '12 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 '12 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 '12 at 15:23
show 5 more comments

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.