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:
PUT HTTP methodAs 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).
