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.onion2k wrote:In general, unless I'm going to have millions of different include files, I use a switch
In contrast, look at how unclear the other suggestions are in comparison.
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:nielsene wrote:Well you aren't stripping out "../"s so its possible that a file could escape the sandbox.
Code: Select all
$string = str_replace('..', '.', $tainted_string);
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.nielsene wrote:It is forced to be a php file so they couldn't show the passwd file.
Roja++Roja wrote:Thats why statements like "I've never had any problems" have no place in a discussion about security.
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.Roja wrote:Correct, because you are going above the root - which makes no sense.
I have no idea what you think you've proven, but try this:Todd_Z wrote:If you tried to include /home/blah/public_html/../../index.php", you would get an error for file not being found.
If you're on Windows, that won't work either, but maybe you get the idea.
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.Roja wrote:They can't VIEW them, they can cause them to be included/executed.
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.