I need a directory with 777 permissions in my webserver; anyway, I would like to protect it by placing it outside the public_html directory. Is this safe enough? A php script will be able to access that directory?
Thank you for your help.
—Albe
So long as your php scripts are sufficiently secure from users trying to break them with SQL injection (amongst others), placing the directory outside the web root is definitely safe to prevent others directly accessing the contents. And yes, php can still access the files, if given an appropriate path to that directory.
yes, the other php scripts can still access that directory, but it will not be reachable over the web.
set the correct owner/group as well,
if you set it to be the owner of the php process a 700 should be working just as well.
David's way is the easiest, but you could also try;
placing a .htacces file in your folder
changing the permissions to 700 (or 750, if you have to be able to edit it with the group)
starting filenames in the directory with a dot (though this is easy to screw up, so you may want to avoid it)
If David's way works, I'd prefer that, but in case you have some weird extra restrictions, these ways MAY work.
Related
I was learning SQLite3 from here; it's really good and portable, but what if someone somehow get to know the database file name say test.db, and then simply downloads it ?
Probably it will be more dangerous than SQL injection, as the attacker can easily get an copy of whole database.
You can restrict .db files in your .htaccess file to do the same add this lines of code in your .htaccess file located in root
<Files ~ "\.db$">
Order allow,deny
Deny from all
</Files>
This will result in an 403 error and will also hide it from being listed in the files list if you (probably you wont) put an index file in an directory.
Just don't keep the data file in a directory that is accessible over HTTP.
If you were using Postgresql or MySQL, you wouldn't keep the data files they used under your web root. The only relevant difference is that databases built around servers tend not to ask you where they should store their data files each time you create a new database (and just stick them somewhere in /var/ based on their default configuration). Don't keep the SQLite files public either.
The question of whether giving people an entire copies of the database is more dangerous than SQL injection is debatable. On the one hand, they get very easy access to all the data, but on the other, they can't change anything on your website.
This question is a consequence of the ubiquity of shared hosting: there is a common view that everything in a project has to go in the web server's document root. However, where possible, it is much better to have a sub-folder in the project for the document root, such as www. You then set up a custom vhost to point to this folder within your project.
That means you are free to create folders elsewhere in the project for files that simply must not be downloadable. I tend to create a folder called /data for SQLite databases.
Unfortunately, not all hosts permit this, in which case #Subhanker's .htaccess approach is a nice solution.
If you have a website, and have different files doing different things, how should you chmod each file?
For example:
A CSS file which controls the layout of the HTML home page. How should I chmod that?
A JS file with functions that give interactivity to the website. How should I chmod that?
And a PHP file which communicates and changes the website's content from the server. How should I chmod that?
I understand how the chmod function works, but I don't understand what files you should chmod in what way. HELP! :D
You should give 750 to PHP file.
For CSS and JS file 644 would be sufficient.
All directories should have 755 permission and all files(php, js, html) should have 644 permission.
As long as the webserver (and all other relevant processes) can access and modify everything it needs to in order to function, you're fine. It needs to be able to read all files it tries to access, and write into directories that it wants to upload files.
I use comprehensive ACLs in order to manage that logically on shared hardware.
$ man setfacl
Unless you have a reason not to (such as multiple users editing files, or you are using webserver-generated directory listings), I always use 711 permissions on all directories. Apache is quite happy with this.
This stops local users from seeing what files you have in there (such as, say, notes, info or config files), and can offer some protection if other settings are misconfigured (+Indexes is turned on, say) or if you don't have the ability to change such settings.
Also, this setting follows the principle of setting minimum required access. (Your mileage may vary on some web apps which need directories to be explicitly readable, but I haven't come across this.)
Im using Capistrano to deploy my PHP project which is going great (other than the fact that its uploading to current/ and i want to go to / but ill figure that out later), but i need some advice as to where i can securely put my config.php file (contains all the mysql connect info) so that it wont be subject to hackers.
Any know any good methods or links?
Every file will be subjected to hackers if they hack the system... The file location isn't critical, but you can put it above public_html in order to prevent clients accessing it directly. Ironically, even if you put it there - the details can leak to the client due to bad PHP configuration (if having inappropriate error level)
Do you use an .htaccess file?
Assuming you're using apache, you can also chown the file to your apache user and chmod it to 600.
I ended up just putting in a directory and added an include .conf file to apache configuration that block access to that directory.
I'm new to CodeIgniter. I notice that all CodeIgniter folders (cache, config, controllers, core, errors, etc...) contains an index.html file that basically says "Directory access is forbidden". Correct me if I'm wrong, but I don't think it is possible to get to any of these folders from the web based on CodeIgniter's default configuration.
What is the purpose of these index.html files? Can I just delete them, or do I leave them alone?
Thanks much.
The purpose of them is to prevent the contents of the directory from displaying if directory listing is enabled on your server. Apache servers by default have directory listing enabled.
There are several instances where given the right circumstances you might be able to attempt to browse to a folder directly. These would mainly be caused by a server which is not configured properly, or an exploit. Therefore it is really best if you just leave the index.html files alone (they aren't hurting anything, and they don't take up that much space).
I'd even go as far as to suggest that you too add an index.html file to any and all folders which you create.
They are there for fail-safes, ie. if for some reason the directory structure would get to be publicly browsable.
I can't see any reason to remove them.
If your codeigniter installation (system and app folders) is outside of your public server directory, then they're not going to help with anything since they could never be served. In that case, it doesn't matter whether they exist or not, since you could never get to their directories anyway.
I say remove them for two reasons:
1) If Apache is configured to allow directory browsing, then it doesn't matter what your index.html says. So claiming that "Directory access if forbidden" when it's really not, amounts to security through obscurity, which is an undesirable security strategy.
2) I disagree with the idea that "if it's not hurting anything, just leave it alone". I've spent many an hour trying to figure out the purpose of a particular piece of code, only later to find out that it wasn't doing anything at all. Remove unused code. The inheritors of your projects will curse you less.
They are for your security, if someone tries to access your folder on the server by your domain URL (if your server is configured in a wrong way), it will prevent you from loading those files by triggering that HTML file
It would be safe for you to keep the file indeed.
Alright, so I have a problem. I need to create a folder to store compiled templates in php. I have an install script that tries to mkdir() an appropriate directory (compiled_templates).
Invariably it returns this warning.
Warning: mkdir() [function.mkdir]: Permission denied in /home/tchalvak/sites/quotesite/quotes/install.php on line 92
Running changing the mode of the folder that the compiled_template folder will be created within also errors out on the same permissions problem.
Is there no way to assure that you can create what amounts to a storage folder via php? You have to use an outside-php program just to ensure that a folder is created? How do other php developers deal with this issue?
Edit: This is an installable script, so the overall objective is to allow 10 different random people to install the script on their server. This is why "making sure that php has all these great necessary write permissions to the compiled_templates directory" isn't practical as a manual process, unfortunately.
Edit: Damn, same permission error when just trying to create a temp directory as well. Lame.
If it's a temporary directory, create the directory in the system temp dir.
mkdir(sys_get_temp_dir() . 'example');
The general approach though is to simply ensure the user PHP is run as (e.g. apache) has write permissions where necessary.
I agree with putting the dir in tmp. To answer the more general question about dealing with this in installer script in general... You should set the perms up on the web root before you run the script and also make sure the perms are correct on any dirs within your package. With that said i generally try to avoid web installers and instead write installers for the CLI version of php. Of course you need ssh access on the box to do that but for me at least its very rarely the case that i dont.
Normally we set up the system to have the appropriate permissions, if that isn't an option your script should fail with a nice descriptive error message and possible solution.
Since you mentioned that you want a temp folder maybe the tmpfile(), tempnam() and sys_get_temp_dir() functions may be useful for you.
If using the system temp directory won't suit you, I've seen creative installers that ask for FTP credentials, and then use FTP to create directories and set permissions.
This may, however, be a bit too clever for it's own good.