Recently, while working on a shared host, I accidentally changed the permissions of my root website directory to 777. The correct permissions should have been 755.
Instantly, I started getting the "Internal Server Error" message for my pages. I figured that the Apache server wanted to stop requests because of a security threat.
I wonder what threat can be caused by giving full permissions to the root directory.
Can someone throw light on that?
Thanks!
If a file chmod is 777, it will be easier for a cracker to upload malicious scripts in your server or modify your pages, etc.
For that reason, only directories where users can upload files should have a public write right.
For your web pages that are not designed to be modified dynamically by the website, a 755 chmod is more secured.
There are a variety of answers, but it maybe that Apache doesn't want .htpasswd and .htaccess files to be readable by anyone.
Related
The problem I have is anything that the Apache user has access to, it will write files to those folders. So any directory with permissions 775 Apache can write to it.
I locked down the server to everything but the uploads folder, as Drupal would not be able to upload if the permissions were not 775.
Inside the upload directory hundreds of files like 3r1bk6bt.php, eh9mq4ov.php are added.
If I delete them they always come back in a day or two. So it is automated.
Additionally when this first happened, it would redirect the sites 50% of the time to spam sites. I stopped that by removing what they added to the .htaccess and index.php files and locked those files down to 640. So Apache could not write to it.
My question is what is the best way to narrow down the root of the problem? Is there common ways that a "redirect apache hack" happens?
I just started working with uploading files via php.
From my understanding you need to set the properties of the folder to 777 so anyone can upload to that location.
That's fine and i only obviously keep information there that is not sensitive, its basically images which are displayed back to the public.
However can someone not just run a delete statement if they know the image name to my server folder or is that only possible if the php file is on my server?
i.e delete myimage.png
Basically my question is other than the normal security precautions like limiting the upload of only .png, using basename etc do i need to take additional security measures to prevent someone deleting files in that folder or can that only be done from a script on my webserver?
I wont be using any post methods to delete images or anything like that but i'm just not sure if its possible to take advantage of a folder with 777 permission and do unauthorized stuff since i gave full access to the folder.
By 777 you're actually giving the read/write/execute access to all the user of the machine where your server lives. Note that this does not mean even website visitors can read/write/execute directly. Its always your webserver (Apache) that does it.
However can someone not just run a delete statement if they know the image name to my server folder or is that only possible if the php file is on my server
If you're PHP scripts have holes then, yes. If your webserver has holes then, yes :)
do i need additional protection on a 777 folder
Yes, you can do with a more restrictive permission. Make the owner of the public upload folder to be apache (mostly www-data), set permissions of just 755, or may be 775 in case even the group wants to write to it.
you can change folder permission 777 to 755 or 744.
Is it possible for hackers ( or other ) to upload/write a php file to a folder on my site that has chmod 777?
Example:
I have a folder that has chmod 777.
That folder contains images.
I use .htaccess to block indexing the folder.
Reformed question:
Can people write a .php file to my folder that has chmod 777 by using a PHP script on their website? For example , to list all the images in that folder
( I'm familiar with the right chmod for uploading folder etc .. , just asking it hypotheticaly )
Chances are very good that any legitimate user of that machine can write .php files, or anything else they want, to that wide-open directory. A 777 directory has almost no place on a shared host. (/tmp may sometimes be 1777, to set the sticky bit on the directory -- that allows only a file owner to delete a file in the directory. Normally, 777 means anyone can delete any file from the directory. But /tmp has definitely fallen out of favor on shared hosting environments because it is inherently unsafe.)
So: Are you the only user on the machine? Or is this machine shared with anyone else? Does this machine run any other services besides web server? If so, those other services might represent a possible attack vector as well.
Furthermore, if your permissions are set to 777 on your directory I wonder just how safe the PHP files you're running are -- I've seen many cases of people running insecure PHP scripts that allow an attacker to modify every HTML file on the entire web server, to infect people browsing the site. (Yes. Many. More than a handful by a lot.)
This is why whichever user account your web server runs as should not own any of the files of the website -- both static pages and dynamic pages. The web server should have only enough write privileges to write its access.log, error.log, and talk with a database server. Any additional privileges beyond this makes it far to easy for an otherwise benign bug in one of your scripts to become an exploitable vulnerability that allows your site to be used for attacking others.
777 is a bad idea. Fix that. Make sure your web server does not have write permission to any of the web content. Make sure no other service on the server has write permission to your web content. Make sure no other users on the server have write permission to your web content.
Update
This is easier than it sounds. Create a new webcontent user. If your web server already has a group of its own, lets use it and call it webgroup. If it doesn't yet, create a new webgroup as well. (adduser(8) and addgroup(8) if your VPS doesn't have its own mechanism.) Then set the owner for all your web content:
chown -R webcontent:webgroup /path/to/web/content
fix permissions:
find /path/to/web/content -type d -print0 | xargs -0 chmod 750
find /path/to/web/content -type f -print0 | xargs -0 chmod 640
then make sure your web server is using the Group webgroup directive to ensure that it can still read all the files it needs.
This will let your web server have read access to all your scripts and configuration, but if the web server itself is hacked, it can't modify any of it.
There are (at least) three ways someone can write to your directory:
If they have local control over the server (e.g. via a terminal)
If your webserver supports and allows the PUT HTTP method
If you have a script that allows people to upload files to that directory
As long as you do not publicly expose the folder in a writable way, no-one can modify the folder's contents remotely. This is regardless of local permissions. The local permissions you have set allow any local user of the server to read, write and execute in this folder - but this does not mean a remote attacker can.
Having said that, avoid 777 permissions unless absolutely necessary/safe.
If your code is on a shared server or a server with other services on it, it'd be possible for the other local users to write to your directory (if the other users are able to descend into the parent directories).
You'll need more than just a directory which is readable and writable by everyone (777) to get hacked. Using permissions 777 generally indicate a bad understanding of security features at all (or laziness when the code needs to be redistributed and the author does not want to make it too difficult by explaining file permissions to the user of the script).
I am trying to set up automated .htaccess updating. This clearly needs to be as secure as possible, however right now the best I can do file permission-wise is 666.
What can I do to setup either my server or php code so that my script's fwrite() command will work with 644 or better? For instance is there a way to set my script(s) to run as owner?
EDIT:
I realized I actually just had a permissions issue, you should be able to use fwrite no problem with 644 permissions. See my answer below.
The apache process should always run as apache:apache - if you must enable write permissions in executable (i.e. DocumentRoot) directories, create a group, add apache and set group write permissions (so 664).
It's best to have .htaccess updated by a cron script reading config data from a database, as giving apache write permissions to executable directories is frowned upon in case a vulnerability in your code allows a malicious user to write new files to those directories.
You can't change the process's owner. If you're on a shared server, see if they have suPHP as an option.
These suggestions were great, however I ultimately realized that the answer to my question is YES - and you shouldn't have to do anything at all... as long as the Owner user of the file/directory you are trying to write to is the same user the script is running as. My mistake was that I accidentally had my file ownership out of whack therefore needed higher permissions 666 and 777 in order to write to my files. Which makes sense because Wordpress can write to .htaccess with standard permissions.
Now I have things setup where a file running as user1 is writing to a file owned by user1:user1, and no problems whatsoever. Directories set to 755, .htaccess file set to 644.
How should I handle image uploading using PHP?
How should I handle the chmod settings?
Example;
I have a dir called /image/ where i want to upload all my images.
Should I set this dir to chmod 777 and leave it like that? Or should i change chmod on that folder via PHP each time I need to upload a image. Is this correct, or should I be doing something else?
As thephpdeveloper mentioned, setting chmod once is enough. All subsequent writes into that directory will not change the directory permissions unless you explicitly chmod it to another permissions somewhere else.
The recommended permissions for directories on a *nix server is 755.
Setting permissions to 777 is not recommended. As mentioned by wic, it gives full permissions to everyone that have access to your server. Which makes it vulnerable if you are on shared hosting or sharing the server with other users.
Also to note is how PHP is run on your server. In fact, if you are running PHP as cgi, example suphp, permissions of 777 for directories are not allowed. Having 777 permissions on the directories your scripts reside in will not run and will instead cause a "500 internal server error" when attempting to execute them.
I recomend chmoding to 755
Only the user running the web server dameon needs permissions to the directory for writing. And you certainly don't want execute permissions on a directory users are uploading to.
Usually, folder settings are set once and that's it. It's rather pointless to keep setting the folder permissions to 777 via PHP, when you have already set it to 777.
No, you dont have to change the permissions on the directory each time. Once set, they are set so to speak.
Using 777 is overkill since it gives full permissions to everyone. Remove the 'x' bit and let apache (or whoever) own the directory. This makes it impossible to list files.