I ask because it seems like the only thing ever called in a proper app index.php file is the require_once bootstrap file. I'm assuming this adds a layer of security but if not, this pattern seems pointless. Why not just use the index.php file as the bootstrap? Any opinions, cautions, thoughts etc. are appreciated!
(By the way, my htaccess file is routing all requests to the index.php file...)
There is no inherent security difference, no matter whether you have your bootstrapoing process in the index file or a separate one.
Having a separate file is usually due to organization concerns (e.g. to have a file that can be included from elsewhere to import your app's functions, or to put all the tasks in properly named files, or to make it especially easy to add custom extensions to the boot process).
However, configuration files containing sensitive information - sometimes, more rarely, even all PHP files at all except for the index file - will be placed outside the web root where possible. That will make a security difference in that PHP files can not be accessed from outside in case of an accidental server misconfiguration.
in a secure enviroment only the index.php lies in the document root, all other PHP files should be outside document root, so it makes sense when the index.php file is only including a Bootstrap file outside the document root.
I don't know of any vulnerability that this exposes. Dropping a blank index.html or index.php into a folder can prevent an attacker from obtaining a directory listing if apache is misconfigured.
Related
Just finished doing a simple mail transfer at my site using PhpMailer
I got 3 question about it -
I have read that's needed to store your credentials on a different file, read that there's 2 options - ini/php, which one would be better and how exactly this file should look like.
Regarding the directory of the credentials file, read it should be located outside the web root (just one level above its fine?), in that case how do I call it from inside the web root?
On the same matter, should the Mail.php itself be located on the site directory? or should I take it out as well?
It's generally safest to put values like these in .php files because they will render to nothing, unlike a .ini file which will usually render as plain text.
Yes, one level above is fine - it means that the file does not have a public URL of its own. From a script running inside the web root, you'd just load it with require '../settings.php';
You don't say what Mail.php is, but generally any other PHP scripts can stay put. Things like class definitions are safe because they have no effect when run directly (or at least should have no effect, if you've written them safely!). That said, it's common to put your composer vendor folder outside the web root since you don't necessarily have control over what ends up in there.
In a way to secure my files from outside access, I am considering placing all the included files outside the public_html folder or the httpdocs folder.
However, this comment is saying that nothing should be kept outside of the public folder that handles user input data.
What is the best and most ideal practice for this? My thinking would be to have a .htaccess point route EVERYTHING to an index.php, and the index.php includes all the neccessary files such as database connections and whatever else, and also includes the .php file which would have the HTML and PHP inside it for the main body content of the page.
Can anyone tell me if there is anything wrong with that, and why?
However, this comment is saying that nothing should be kept outside of the public folder that handles user input data.
The comment uses the word direct. Includes are handling the data indirectly.
My thinking would be to have a .htaccess
Configuration is better handled in the main configuration file if possible. .htaccess marginally is less efficient (and scatters configuration across your webroot).
point route EVERYTHING to an index.php, and the index.php includes all the neccessary files such as database connections and whatever else, and also
The front controller pattern is a perfectly reasonable approach.
includes the .php file which would have the HTML and PHP inside it for the main body content of the page.
Simply including that can start to create a bit of a mess. I suggest investigating the MVC pattern.
The comment you are referring to says that nothing that handles input or output directly should be outside the document root.
On the other hand, it's perfectly fine to place library code outside the root. If you use index.php as a single entry point to your application, pretty much the only things that should be web-accessible in addition to that script would be your assets (css, js, images, etc).
Currently, for things like a header, footer or common sidebar object, I create a custom .php file and do something along these lines:
echo '
<some><html><here>
';
and then include it on the pages that I want it to appear:
include('path/to/file');
The only problem with this is that someone can point their browser to my .php file and view part of html on its own. It isn't a huge deal, but it seems unprofessional and a little careless. Is there a better way of doing this?
The simplest way is to move all those files outside the DocumentRoot / public directory and include them from there. Something like:
include '../pages/header.php';
// rest of the script
include '../pages/bottom.php';
Anyway that's the purpose of that directory - to only hold things that are meant to be accessed directly.
Of course, the first step after this would be to look into having only one index.php file which filters all the requests (permissions, filtering, rewrites, etc) and includes whatever is necessary based on the request (this is called a Front Controller and there are also a few lightweight frameworks which already implement it). Here's a starting point: https://github.com/adrian-gheorghe/basic-website/blob/master/public/index.php
Put the included php files in a separate directory, and make this directory inaccessible from the outside (using .htaccess with Apache, for example).
You must restrain the access to other files in the server configuration.
WordPress pretty much does what you are currently doing: it stores all of the theme files in /wp-content/themes/THEMENAMEHERE/, and you can access the files to there directly. It's not that big of a concern, as users can't exactly do anything harmful, but if you care, you can store your files in a separate directory (as other answers have mentioned), or configure httpd.conf or .htaccess to block access to the particular scripts.
I am developing a web application. contents are:
root dir (/var/www/)
config.php
index.php
details.php
admin dir (/var/www/admin)
admin.php
I have included config.php file into index.php, details.php in root directory using require_once('config.php') as this file contains database passwords, styles, images directory paths..
how can i include that config files in my admin/admin.php file so that one config file can be used in anywhere(even in subdirectories) of my web application. Will it make any difference for the value of define('APP_BASE_PATH', dirname(__FILE__)); when same config file is used by all files in the web application.
if i am wrong somewhere then please get me right.
If your server properly configured, just
include $_SERVER['DOCUMENT_ROOT']."/config.php";
anywhere
You have also 2 other possible ways.
a Front controller setup, where ALL user requests going into one file. And ths one going to include all others from their subdirectories. Personally I don't like it cause this front file become a mess. Though it's widely used.
I decided not to mention it because noone would use a hardcoded full path anyway.
Update after clarification in comments: You are looking for a way to include a central configuration file from anywhere in your project's folder structure.
#Col. Shrapnel shows one way, DOCUMENT_ROOT. It's the only way to use an "absolute" path from a nested folder structure. It has the limitation I describe above, but it's fine otherwise.
If you want maximum portability (i.e. the possibility to run the app with e.g. www.example.com/myapp/version_1 as its root directory), you would have to use relative references from within your folder structure to "climb down" to the config file, e.g. ../../config.php that will work reliably too, although be a bit cumbersome e.g. if you move a script to a different folder and you have to update the relative path.
you can use the same config file every time... using "/" will take you back to the root directory... so in admin/admin.php use this:
require_once("/config.php");
you can use "../" to take you up one directory eg:
require_once("../config.php");
was this what you were looking for?
I was looking at templating systems for php, and I've come to believe that pure php code seems to be the solution I want to use.
I'm the lone developer, so there's no designers who need a nerfed arena to work in. Template engines like smarty seem to suffer from the "Inner-platform effect". If I stick with good practices ( pre-computed values, use only foreach ), I think this will work.
My goal is to have a single source for the string of the html shared by each page. My thought is that a separate php file, accessed via include, is a good way to meet this goal.
However, I'm concerned that that might pose a security hazard for the site -- I can't think of anything specific at the moment, but someone could guess the name of the template and request it directly, perhaps exposing something they needn't see. (I suppose I could put in a check to see if it itself is the request.) I have a hunch this could be bad, so I don't want to go ahead and do it, create what I feared would happen, and then throw that work away.
If a separate file is not the best idea, what else should I use to basically store a string for the whole site? A string constant in an include, that I could use in sprintf()? A function that returns the html string from arguments of the page-specific html parts?
Files that should not be served via HTTP should be stored in a directory from which your webserver will not allow anything (not PHP, at least) to be served to the users.
Two possibilities :
put those files outside of the DocumentRoot
or put those files in a sub-directory, from which Apache will not be able to serve any file.
Such "not served" files generally include stuff like :
configuration files
libraries / frameworks
data files (like an SQLite database, for instance ; or i18n files)
The first solution : your directories could look like this :
data/
i18n/
i18n/your-file-here.php
library/
www/ <- this is Apache's DocumentRoot
index.php
another-php-file.php
And for the second solution, just disable access to the directory containing your "data" or "libraries" files, putting in it a .htaccess (If your webserver is Apache) file containing something like
Deny From All
With that, Apache will not allow anyone to directly access via HTTP the files in that directory, but your executable PHP script (in another directory) will still be able to include them.
Simple, really; Name the file whatever you want, but use ".inc.php" as the extension, then include this line at the top of the file:
if (basename(__FILE__) == basename($_SERVER['SCRIPT_FILENAME'])) {
die;
}
this will kill the script if the file is accessed directly.
EDIT: Pascal Martin's solution is probably more in keeping with BCP, whereas mine is more quick-and-dirty. I've used both, and either seems to be fine.
I like using a separate template file as well. Generally I'll define a constant in my config file and then put a check for that constant at the top of the included file like such:
Set constant in config:
define('_VALIDPAGE', true);
Check constant in included file:
defined('_VALIDPAGE') or die('Not allowed');
This makes it so that the included file can only be loaded from within your application.
you're right in that php is a fine templating system in itself, as long as you stick to a certain subset of it in the "template" files. but insistance on a single template per web page is impractical: more often than not you'll find that you have fragments duplicated over several templates.
anyway, separate files are fine. putting templates into a directory (tree) separate from the source directory (tree) is in my experience bad idea: the conceptual distance grows, you loose sight of what's really used and what's not, and as a result, you have quite a few templates that are dead but not buried, since their state is not so obvious.
my suggestion: keep the "templates" together with "program" files, protected with appropriate web server configuration
DocumentRoot /www
AddType application/x-httpd-php .php
<Files ~ \.tpl$>
deny from all
</Files>
/www/
dir1/
file.php
file.tpl
another-file.tpl
dir2/
other-file.php
other-file.tpl
yet-another-file.tpl
...
common/
shared-file.tpl
another.tpl