Page 6 - [Everyone] Must read Security Notes

rycamor,

You make a valid point AFA open source, distributed applications go. However, for code that is not open source, who would know that $PATH_INCLUDE is a session variable? Granted it's not good practice and I'm certainly not advocating leaving such holes, but without access to the source it is pretty much a non-issue as far as security goes.

Still thats a nice thing he pointed out.

I am myself not using constants.

I will now think about incorporating it some or other way.

JD

The problem with register_globals is that it makes all GPC variables available as globals, aswell as your variables. Thus someone can set a get variable, which if your code hasnt set, may be used as one of your globals. Without register_globals it means that if you access a global variable $auth, it cannot have been set by the user. Ofcourse if you write it carefully you can write secure code with register_globals on, but the majority (in my experience) of php programmers pay little or no attention to making their code secure. This has shown to be a problem in big open source projects like phpmyadmin, aswell as small websites that some amateur hacker destroys by fiddling with urls. In the last few years i've heard so many stories in the news of people changin urls on BIG companies websites, and getting other peoples bank details, creditcard details, messing with databases, etc (ok, so mostly these probably werent php sites, but same applies). People will mess with urls and post/cookie data, especially wanna-be hackers!

I think that register_globals is a very useful feature of php, and makes programming quicker and less messy, but, it is also a feature that without care leads to a lot of insecurity in code, which would otherwise be more secure.

I use E_ALL as a tool, to simplify my coding. It warns me when I've forgotten to declare a variable, it warns me when I've forgotten to declare default values for functions that accept a variable number of parameters (which IMHO is a good practice), and it generally *helps* me in doing my job.

The live version of the site should naturally run with no error reporting at all and good logging facilities aswell as internal error handling routines.

Developing with register_globals off is a must if you want to make portable code, just like you have to handle magic_qutoes and other .ini settings in a portable way. If you write code to sell or redistribute somehow, these portability issues should be the first you resolve.

This is just a quick post about what the original author said about .inc files being viewable by anyone who types in the name in their browser.
What I do is i put my PHP library/utilitiy scripts below the document root, which stops people getting at them from apache.

For example
assume document root is /home/someuser/www.example.com
and all the .inc's are in /home/someuser/include
you would do a php include like this:

include($DOCUMENT_ROOT."/../include/example.inc");

that way the only thing exposed to the outside world via apache are the php files for the pages in your site, which they can't see anyway.

Anyway, this might be of interest to some people who have a problem with people viewing .inc's or the like, or who dont like having example.inc.php type files round the place.

Jason

That's fine for library files, but I use a lot of includes when building my sites and putting them outside the webtree would make things messy, so we have our webserver set up to deny request for .inc files, simple as that.

Yep, thats a good solution as well.
Although i dont like to have .pll's (my version of .inc) scattered across the site tree. I like to have everything structured.
I.E.
all libs and includes go in DOC_ROOT/../include
rest of the actual php pages go in DOC_ROOT/whatever

I just call a wrapper function: fc_include("example.pll") and it takes care of everything. So in the document root I would have only page1.php, page2.php, page3.php etc etc.

I just think that this way is cleaner, but each to his own I guess.

Jason

I keep hearing people say .inc.php files are just as bad but no one has provided an example other than the kind of thing Jason said that people don't "like" them, whatever that means. Heh.

I see no reason to name them .inc and go through the trouble of setting up Apache to deny them, or moving them outside of your doc root. Why not just do it right the first time so you don't have to hack up a solution to get around the original problem? And what about portability? You can't expect all of your users to take the kind of care you do with your inc files, many of them may not even set up Apache to deny requests for .inc files and they may not [be able to] put them outside of their doc root. If you simply name the file .inc.php you eliminate the problem.. So I don't know why this discussion keeps being brought up like we need to hack up solutions to this problem when it's so easy to solve.

Well, the most important reason is that I don't want my .inc files to be run outside of their context. If they are named .inc.php that's possible, and I don't want it to be. Maybe I'm just being paranoid, but that's my reason.

Encapsulate all your code in functions so the code won't be executed if the page is called. Good practice aswell.
Lots of thanks to JeffCT fo his thoughts,,,

There shouldn't be any executable code in a .inc file anyway. How are they going to be run outside of their "context"? Explain.

I generally build my sites using included files, so normally the only .php file is index.php, the rest is built from this file. This means that I have a lot of executable code in .inc files, and because of this I don't want them to be run outside of their context (by that I mean outside of where they are supposed to be included). This goes regardless of whether I name the files .inc or .php, I simply don't want them to be executed alone, and to do this I name them .inc and deny access to them.

A way of writing your applications using only the index page (the way you like it) could be somthing like this....This way you will avoid all the trouble you are going through with denying files...

index.php




baseclass.php


email.php

Try it if you like it...Makes your pages very easy to modify

Eh... All the trouble? It's one bloody line in the apache config, and once it's done I never have to worry about it...

Anyway, I don't like creating classes and functions that are used one single time for one single purpose -- it seems like such a waste and IMO is not a good use of classes. The classes will also be very messy because I need to put all the HTML in there, and I will have to somehow pass all the data to the functions (either using parameters or using globals).
Remember that my pages contain mostly dynamic data, and all this data is usually loaded by one segment of code.

I did use a similiar approach on one website I did, but I found that the extra work didn't really pay off, the most important thing is to get repeated work factored out as separate components, and to have a neat physical structure on everything. My current solution which uses mainly includes to do the physical organization works quite nicely, it still has the disadvantage of each display component demanding certain data from the dataloader component, and they both have to agree on the naming of this data.

I'm always thinking of ways to improve on this organization, and in future projects I will hopefully come up with even better ways...