Separating include from public directory
Moderator: General Moderators
Separating include from public directory
Could someone help me find some resource on separating the files for inclusion from the public folder. I couldn't find anything searching for similar things.
Whichever uid php is running under has to have read permission in order to be able to include the file.
Php also has to be be able to read through the filesystem to the file - ie dirs en route must have the execute permission for the php uid.
With php running as a server module, it has the uid of the server. From the command line, it's running under your login uid.
Php also has to be be able to read through the filesystem to the file - ie dirs en route must have the execute permission for the php uid.
With php running as a server module, it has the uid of the server. From the command line, it's running under your login uid.
What I am trying to figure out I guess is this: right now I have all my files for my website in the www public folder. This includes all the setting and classes and everthing that my site is run on. Is there any security risk with that? aren't you supposed to separate the includes that have some of that info to a folder where the public can't see it, only the server?
The risk is if someone can run your code in ways which you didn't intend. Anyone can aim the browser at any file on your site - unless there's a server directive which says otherwise.
Even then, that's not necessarily a problem. There would have to be a script which can be manipulated in a harmful way. Normally all my include files are just class definitions. If someone could poi8nt a browser at the file, nothing happens. There's no code to actually instantiate an object or issue commands. The file, if it's a type recognised as php by the server, gets parsed and no output is created, just a blank screen.
If on the other hand, you've got code which does actually do something it will execute - or try to: it may not make any sense out of context. If it's a script to delete a directory tree, and the hacker can supply a folder value (they'd need to know the variable name and probably - though not necessarily - register globals would have to be on) then the script could be run as is without going through all the validation etc checks which might have been in the main script into which the file is supposed to be included.
Really, it's not good design to include active bits of code in the first place but if they're there yes it's better to keep them off root. Use an .htaccess file (deny from all) if you can't get out of the web root.
Even then, that's not necessarily a problem. There would have to be a script which can be manipulated in a harmful way. Normally all my include files are just class definitions. If someone could poi8nt a browser at the file, nothing happens. There's no code to actually instantiate an object or issue commands. The file, if it's a type recognised as php by the server, gets parsed and no output is created, just a blank screen.
If on the other hand, you've got code which does actually do something it will execute - or try to: it may not make any sense out of context. If it's a script to delete a directory tree, and the hacker can supply a folder value (they'd need to know the variable name and probably - though not necessarily - register globals would have to be on) then the script could be run as is without going through all the validation etc checks which might have been in the main script into which the file is supposed to be included.
Really, it's not good design to include active bits of code in the first place but if they're there yes it's better to keep them off root. Use an .htaccess file (deny from all) if you can't get out of the web root.