To ensure website security we’re always running the rule over the sites we host; whether that’s as part of our layered, automated security systems or as part of a manual review. We recently conducted and completed a review of file permissions across several servers – with a goal to countering basic points of intrusion on hosted sites. The target this time? Insecure directory permissions. First a little background on permissions…
At a very basic level, every website and server operates as a collection of files and directories. In order to function as intended, every file and directory requires specific pieces of information we refer to as permissions; namely the ability to be written to, to be read and to be executed.
It will also hold information about who is allowed to do these things on a case by case basis. These are separated out into; the owner of the file or directory (typically an FTP user), a member of the server group (typically a shared service on the server or an FTP user depending on the level of security on the file), and everyone else. This last group is especially important as depending on how your site is configured, this literally refers to everyone with access of any kind and is something I will circle back to later.
You will usually see this represented simply as three numbers, for example 644.
These numbers are a combination of:
These three numbers refer to specific people or groups that have access to the file. 644 is typically the standard recommended secure permission for files on a server that require people to be able to view them (e.g. index.php).
644 indicates the owner of the file is allowed to read and write to the file but not execute and that both the shared groups and ‘everyone else’ is able to read the contents of the file but do nothing further with it. This is important because if an index.php file cannot be read by ‘everyone else’ then it can’t be loaded via a browser for your end users.
At first glance, it might be assumed that a text file being read and executed are effectively the same thing or that a file may require execution rights, however typically this is not the case for it to function as intended.
As you can imagine, if a user included in the ‘everyone else’ group (which includes anyone able to browse your website!) was able to either write or execute a file on your server, this could cause you some very serious problems! Write permissions allow for anyone in the last group to edit the content of your site without your permission, however execute permissions are far worse. A file with execute permissions can run scripts that directly impact services as well as many forms of malicious activity.
What each of these permissions mean and the function they allow is slightly different whether you’re talking about a file or a directory. In order for a directory and its contents to be visible and accessible to users, it requires both the read and execute permissions. A directory without execute permissions can’t have its content browsed.
Typically, a standard web-browser user will require a permission of 5; read and execute on any directory in which the files should be accessible to be read but the top level owner would require the ability to read, write, and execute (7). This allows them to change the contents of the directory.
Therefore, for standard functionality a directory will typically have the permissions set to 755 which allows full access for the owner, the shared group (used by server services) to read and execute (in order to open directories), and the ‘everyone else’ group to read and execute (to open directories).
Within those directories files will typically by default have 644 permissions. This allows the owner to read and write but not execute files (which allows you to edit and open files to see their contents) and both the services and ‘everyone else’ groups to read the files only. It is important to note that for the vast majority of files on websites, these permissions are the most required for any level of functionality.
If you go back far enough, certain services had issues with writing to files within directories which would often cause issues with sites loading. A simple solution to this problem, employed by a wide variety of site developers, was to simply set directories to have 777 permissions, which as discussed above means that the owner, the shared services group, and everyone else (meaning anyone who can access the website!) had the ability to read, write and execute files within that directory.
If the existing files have 644 permissions so that they cannot be altered by anyone but the owner, this isn’t necessarily a problem implicitly (though it’s certainly a risk). The problem arises when someone gains access to the site through other means (such as a brute force attack), resulting in them having access to uploading or creating new files within that directory. Once they create a file with executable permissions within a directory that has 777 permissions, they have free reign to cause a lot of mayhem! This is typically the kind of behaviour you will see during a hack.
Thankfully, due to changes in the way servers are run, file ownerships are configured, and updates to PHP and similar, there are almost never scenarios now where anyone should have difficulty writing to a relevant file and thus the default permissions need never be altered. So 777 permissions are a thing of the past and we almost never see anyone with a newly built site using these.
Unfortunately, a number of sites where this may have been necessary from their developer’s standpoint, for them to use in the past, still exist with those 777 permissions and thus present a security risk.
We recently encountered a site on our shared hosting platform, whose website had been hacked due to insecure passwords. Unfortunately, it would seem they were also one such website! This resulted in a server wide issue wherein all website users who were using 777 permissions (keeping in mind that this leaves the directory open to literally anyone) were able to have malicious files and code injected into their site.
This has been addressed and the users affected notified, however there are still a large number of websites on our shared hosting platform where these outdated and insecure permissions are being used.
It is important to note that if your own directory and file permissions have not been changed from the defaults, then these insecure directories do not affect you directly and you do not need to be concerned. Only users who have weakened their permissions are affected by this.
In order to protect our servers and users, we are now taking proactive measures to prevent this from occurring. Specifically, across our entire shared hosting platform all users with directory permissions of 777 are being forced to the effective and secure defaults of 755.
Due to the latest server configurations, this should have no impact on site functionality, save for making things safer for everyone and reducing stability risks for the overall server.
Should you have any concerns or issues, you are of course welcome and encouraged to reach out to our support team.