In general, unless I'm going to have millions of different include files, I use a switch
This is an excellent approach and one I often recommend. It's very clear, plus it doesn't depend on any variables. Hard coded strings are very safe and obvious.
In contrast, look at how unclear the other suggestions are in comparison.
Well you aren't stripping out "../"s so its possible that a file could escape the sandbox.
One security principle to which I adhere (or try to) is to never try to correct invalid data. When you do, you create an opportunity for you to make a mistake that yields a security vulnerability. For example, here is an approach I have observed quite frequently:
$string = str_replace('..', '.', $tainted_string);
Can you think of a way around this?
It is forced to be a php file so they couldn't show the passwd file.
That's not true. The way include works is the file (or resource) you reference is treated just like any other PHP file. If there are no PHP blocks, it's treated as raw output.
Thats why statements like "I've never had any problems" have no place in a discussion about security.
Correct, because you are going above the root - which makes no sense.
What he said isn't correct, because going above root doesn't fail. Maybe it does on Windows or something, but the parent directory of root is root.
If you tried to include /home/blah/public_html/../../index.php", you would get an error for file not being found.
I have no idea what you think you've proven, but try this:
If you're on Windows, that won't work either, but maybe you get the idea.
They can't VIEW them, they can cause them to be included/executed.
Includes are treated just like any other PHP file. The only code that is executed is within PHP blocks. Everything else is just raw output.
So, if you're referring to his example of index.php, you're right. If this is the case, just be careful to qualify your statements. :-)
Hope that helps.