Possible exploit - folder 777

Hi =)

I have a script that loads files from a templates folder which I have set to 777 as you can modify the templates with the script. However my host has said that being 777 it gets open to exploits....
what do you do?
LVL 10
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

> what do you do?
save templates into database
ask Your host to impove php security (like suPHP)
The directory permissions are too wide for your requirement.  

For example, you are using "7" which is READ + WRITE + EXECUTE FOR ALL.  You dont need any of your scripts to have EXECUTE permissions on the directory.  If they *do* require EXECUTE, then the scripts need to be changed so that they dont need to 'cd' into that directory.  You should be able to start with a minimum of 766 which means:


You should also put a "htaccass" file in the directory so that anybody who attempts to use the directory as a URL and read ALL your templates will be offered a username/password dialog, and be refused access.

You should take a good look at your scripts and the architecture you have and try to find the best code and minimum permissions required to make your application work.  One good method is to change the owner of the directory and the templates to be the same as the web server process, and lock the permissions down to 700 for the directory and 400 for the files.  This would be my preferred approach, but it depends on the configuration/setup of your host server.

wildzeroAuthor Commented:
Ah some good tips there - points upped as they will be split at the end of this.

>>  If they *do* require EXECUTE, then the scripts need to be changed so that they dont need to 'cd' into that directory.  You >>should be able to start with a minimum of 766 which means

Normally the templates are located in another folder, ie templates/ so I guess the script would need to cd into that directory.

>>You should also put a "htaccass" file in the directory so that anybody who attempts to use the directory as a URL and read >>ALL your templates will be offered a username/password dialog, and be refused access.

Excellent suggestion, never thought of that, as the script is just called it via fileserver (ie, fileopen('templates/somthing.html') then that's not handled by apache so therefore ignores the htaccess, however anyuser trying to access the folder would be denied.

>>save templates into database
I can see how that would be ok if it was just for myself, however if I was giving the script away - sure the users could do it but it's another step for them to do (setting up a db) where as just providing template files is 10% easier.

>>ask Your host to impove php security (like suPHP)
As above...

Thanks for the comments guys, points upped.

Become a Certified Penetration Testing Engineer

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.


1) The script does not need to 'cd' into the directory, you only need to refer to the files with the directory in the path, for example:


   When you do this, your script does not need EXECUTE permissions.

2) If you are giving the script away, you can provide an installation script that is run through the browser.  That script would create the templates directory, and explode some zipfile of templates into the folder.  The advantage of this is that the directory and the files are created by the web server user, so they are accessible by the runtime php environment, *and* the directory and files can be permissioned as 755 & 644 respectively.  This is a common approach.  Note that can create an htaccess file during this process with the user prompted for the user/pass that they want to protect the folder with - this is a double layer of protection.

Oh, and this is a typical problem, and not a sign of weak host security.  If your server is configured with very tight security permissions that do not allow you to have a directory that is 777, then some applications/frameworks will not work on your system.  There is no reason why 777 should *never* be used, although it should be used only in well managed circumstances.

Normally the templates are located in another folder, ie templates/ so I guess the script would need to cd into that directory.

There's no 'cd' in a PHP script.  you are either doing an include('templates/somefile.htm') when live-loading the content, or an fopen('templates/somefile.htm', 'rw') if opening for reading and writing (i.e., editing).

There are lots of permission issues across hosts.  You can attempt to change permissions from your script, but it won't always work -- so make sure your documentation instructs a user at a basic level what they might need to change.

755 for folders and 644 for files should be 'good enough' for properly-configured hosts -- those which run apache/php as YOUR user.  However, for a badly configured host, you might find you need 775/664 access as 'nobody' or 'apache' or some such user is running apache/php.

Excellent suggestion, never thought of that, as the script is just called it via fileserver (ie, fileopen('templates/somthing.html') then that's not handled by apache so therefore ignores the htaccess, however anyuser trying to access the folder would be denied.

FYI, htaccess is not always set up (or set up properly) on many cheapo shared hosts -- some have it pretty screwy (like no htaccess, or only in your root, and only certain commands...).  You are better off adding a line or two to the top of each file to check if it's being directly-loaded by the browser, and if so die immediately.


I have some comments on your notes - please note that I just want to make sure people have the correct information, I respect your work/answers and have even used a couple of your PHP library scripts from time to time.  So, no criticism of you, just comments that clarify points you have raised.

(1) "There's no 'cd' in a PHP script"

There *is* a cd in a PHP script, take a look at the details at [http://www.php.net/chdir].

Note that I am not suggesting that wildzero actually *is* doing a 'cd', just that he doesn't need to.  I have no knowledge of the scripts that he has written.  The important thing to note is that you do not need EXECUTE permissions on a directory to read a file from within it.  So for example, if you 'include' a file from a directory, then that directory and the file only needs to have READ (4) permissions available for the user under which the web server process is run.  In most cases the web server process is run by a user that is not in the same group as the user who owns the files, so it must be world permissions that need to be available:  744 will work on a directory you need access to, 644 on readable files, and 666 on writeable files.

By giving 666 to a writeable files, this does not mean that somebody can edit the file from the internet in any way that is not managed by your script.  What it does mean is that anyone with access to the same hosting network as you can modify the files.  So you *do* have the added protection of the security around the hosting server itself.  However 777 should not be set on a directory, since this makes the directory (which is a file itself) executable and editable.  It is possible to inject information into a directory file that will compromise the security of a unix server.

(2) "you are either doing an include(...) ... or an fopen(...)

There are lots more ways to open a file than with include() or fopen(), so your assumption is pretty tight if you dont mind me saying so ;-)

(3) "You can attempt to change permissions from your script, but it won't always work "

As you know, the ability to change the permissions on a file created at runtime is affected by the permissions of the file or directory you are creating and the ownership/permission on the directory in which it is created.  The method I describe for installing files that are to be delivered at runtime is quite common (some major PHP products use this technique), and works around the problems that windzero is facing for a pcakcged product.

The principle is that during installation, the user creates a directory manually with world writeable permissions, then runs the installation script.  During installation, files/directories might be created which are then used for files which might be modified at runtime in the future.  The installation process creates these files/directories as the web server user so that in future the files can be delivered or modified by the web server user at runtime.

The only problem comes into play when the script attempts to chmod() the files/directories.  If PHP is being run in safe mode, the script can not chmod the files - instead the you need to alert the user that a series of commands must be run manually on the server (or using an FTP client) to complete the required permissioning model.

(4) "htaccess is not always set up (or set up properly) on many cheapo shared hosts"

I agree, but on the subject of htaccess, my view is that if a host doesn't support it, dont use that hosting company.  I also completely agree that you should provide additional protection by placing index.php files that die with a 405 (Not Permissioned) error in any read-only directory, and additional lines in 'included' files that also die with a 405 error if an attempt is made to open that include file in a browser, instead of an include statement in another PHP script.

Ho Hum...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
hey sb-  no problemo.  always good to clarify things around EE! ;)

(1) I guess I've never used chdir under PHP, and those things I might think of using it for take path specifiers anyway (whereas under certain languages there are more ops that only work on the current directory).  Things like opendir take a path, so /templates could be specified and read without ever 'cd'ing.

To simplify your other note: the reason to set permissions 'somewhat tightly' is usually around other people's code being exploited, and then if your files/dirs aren't protected they can be accessed via another user account. ;)

(2) well, for locally-opened files, it's either an include codepath or an fopen path (fopen being the root of numerous higher-level calls like readfile and such...).  I guess if you wanted to expand into extensions, yes then there are other ways to open local files...  Though I would hope they all patch through the core fopen code (as it'd be potential for exploits otherwise!).

(3) Yes, my second statement was clearly referring to whether or not you can do a chmod on a given server.  Sometimes disabled to avoid potential exploits/issues. ;)  I try not to rely on it, but that's me.

(4) We're on the same wavelength on this... ;)  Unfortunately, choice of providers, and moving providers, isn't always a simple equation -- and few, if any, give you an easy way to go through a checklist of 'yeah, we don't let you do that' stuff.


(1) I never use it either unless I'm writing a non-web-server application in PHP, which is rare.  If one of my coders uses it in a web app, they are strongly advised to re-work the code ;-)

(2) Slightly disagree, for a purist, I guess fopen is the default, but for lots of reasons it's good to understand the reasons for choosing and using file_get_contents() and file()   For example - to quote Zend themselves from the http://uk2.php.net/file_get_contents page: "file_get_contents() is the preferred way to read the contents of a file into a string. It will use memory mapping techniques if supported by your OS to enhance performance."

(3) Agree - I choose not to use chmod if at all possible.

(4) You can always ask on Experts Exchange ;-D
interesting point on file_get_contents.  I've never made much use of it as I was 'brought up' on fopen, and file_get_contents only appeared in PHP 4.3.x... and obv hosts don't upgrade things like PHP that quickly. ;)

it's not actually clear in any of the docs whether the memory mapping is done at the fopen level or whether file_get_contents is doing something special (maybe setting a low-level flag, THEN calling through to fopen, then resetting flag...).  I'll have to go mod my various code, see if it makes a difference.  Obviously makes things cleaner!  But for a classical programmer, I'm so used to fopen-style coding -- since I open the file rw, read it, do some stuff, write it, close it.  I don't know if that's slower than file_get_contents, modify, file_put_contents... hmm.

Good thoughts here!

(oh, and I just realized file_get_contents arguably is only useful for raw string data, and not binaries... and _put is only in PHP5... ah well... )
wildzeroAuthor Commented:
Lots of good opinions here.
Sound like making the templates folder via the script, unzipping the templates to that directory along with htaccess and an index.php would be the best solution.

So my next question (mabye I should put in another question)
Whats the best way to
* Give the user a zip file ie templates.zip
* Run some php which unzips the templates.zip and puts them into a templates folder.

Anyone have an article on that?
Points upped
I usually do all my script distribution AS zip files, not raw individual files.  Inside, I'd have a folder that is <templates>, with all the defaults included.  My readme would say:
- copy the <zzzzz> folder to your server, including contents, and set the permissions on the folder to ###.

Users can generally follow those instructions.  I wouldnt want to rely on unzipping something up on the server myself, but that's just me.  I'd rather have the user upload the folder and contents directly.  Again, just me.  I do know there are people who do sub-zipped contents, but I've yet to actually download a script packaged that way.

There is a Zip library/extension for PHP.  Never used it.  Has a dependency on some secondary lib, and not all servers have it installed...

wildzeroAuthor Commented:
davebytes  - yes that is how I usually do it as well, but looks like there are more secure ways of doing it...

You two had better go take a look at some of the leading PHP products, and take a look at well written installers.

In particular, I recommend you look at Joomla/Mambo, and see how that award winning CMS system installs, and then how you can load components/templates/modules as zip files.

You should also look at J2EE architecture, and the way applications are distributed as WAR or EAR files.  These are zip files that contain all the classes needed to run an application.

Or to put it into the words of the Blue Oyster Cult - Please don't fear the Zipper.

...or did I get that wrong...  "please dont fear the hmmm mmm?  "..  'please dont..     oh never mind.

Nothing wrong with unzipping files, and you're going to see a lot more of it - get used to it
wildzeroAuthor Commented:
Points upped again,

Thanks for that siliconbrit - it does seem that having the zips is easier and it also helps with the file permissions it seems.

Any more comments?
having zip files doesn't help with file permissions in the slightest...

I guess I've worked on so much stuff that needed some hand tweaking, I've never looked at Joomla -- I'll have to see what they do.  It's been discussed in WordPress circles that zipfiles might be handy for distribution of extra modules, and I've seen some other CMS products that do things that way, but seems few and far between.  Not sure if that's just a mindset issue, historical problems with unzipping, historical problems with permissions running as apache, etc.

From my 'other life', I've been using 'packed' files for distribution for well over a decade.  My old game engine used a packed but not compressed format, and certainly quake/et.al. have used pak/zip formats for content for many years... so it's far from alien, just not 'used' to it in my web development world. ;)



I have 22 years of development.  Yes, I know - dont say it.

I used to distro everything by tar, but that's just an old UNIX habit.  I still depend on tar files when I specifically want to set permissions/ownership when the file is unpacked, but that's just never going to be a zip feature.

I started using zip when it was used by Java to pack the code.  It seemed pretty alien at the time, since Java is a semi-compiled language, but when I got used to it, it made much more sense for anything that is not fully compiled, and even then, why not?

On a Java Application Server, JAR or EAR files are unzipped at runtime (!) by the application server itself, and inside the zipfile is a whole directory structure, a manifest and all the bytecode class files.   Yes, this does seem alien, until you realise that a C compiled program is just the same information (DATA Segment, CODE Segment, Pragma, etc) all compiled and COMPRESSED into a binary executable.

If you are willing to accept that concept, then the idea of using a zipfile to distribute code written in an interpreted language like PHP is not such a big leap of faith.  After all, the local OS will deal with creating the filesystem rather than you having to script it, and you dont have to code for any OS differences, which we are all about these days.

Ho Hum.
wildzeroAuthor Commented:
=) awesome info guys
points upped one final time
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.