I have a php class that connects to a database which has the password to the database hard coded into it. I do NOT have have access to folders outside the webroot. Reading this forum and others it seemed that creating a htaccess file with
order allow,deny
deny from all
in the directory with my php classes would do the trick. however after doing some quick testing it seems this also blocks the public files which need access to the database to generate the site. to be clear this is the structure i want:
index.php (public file which calls on php classes that access the database)
php_classes/DatabaseConnect.php (contains the password to the database. i want to hide this from everything that is not uploaded onto mysite --- or better yet only to specific files i name)
...
thanks,
brook
Do not place your PHP code in the webroot. Frameworks will typically use this technique where they only put a bootstrap file in the webroot...you can do that same and place your PHP file with sensitve information above your web root so it cannot be browsed.
Your bootstrap file would #require_once '../safe_dir_above_webroot'.
If you're worried about others seeing the login details to your database, rest assure that it cannot be seen if inserted between PHP tags.
.htaccess is a little tricky with some servers. It seems quite a few setups hate overruling which I can understand.
Since you have suggested that you cannot access folders outside of the root directory, you may just want to do something like this.
define("include_allowed", true);
Call that in the leading file, for instance index.php. When a file is included it should check to see if include_allowed has been set true.
if (include_allowed != true) header('HTTP/1.1 404 Not Found');
This checks to see if it has been included by index.php or which ever file that has defined include_allowed true.
If it fails to return true, a 404 error is sent saying not found to trick users! :)
Since your file is PHP , it will processed by the PHP exe, before being rendered to the client. So the password should not be visible. Having said that to use htaccess to stop view a particular file you can do this
<Files php_classes/DatabaseConnect.php>
Deny From All
</Files>
Related
I need some help.
I was reading the security recommendations of my hosting service and they say that ideally just put the
index file and files like css, js and img inside my root folder, and that all other files should be placed
off, that is, a level above.
I tried doing this in my tests, and I had some problems. The structure of the hosting folders is:
/
/htdocs
Inside /htdocs I put the index.php file and when accessing it through the url exemple.com/index.php works normally.
But putting other test files out of htdocs is what starts the problem. For example, if I have a file called contact.php
and I try to access it through the url exemple.com/contact.php I get the 404 error message.
So the question I have to ask is:
Is it possible to access url files that are outside of htdocs, or better to put all the files that will be accessed by the url inside
of htdocs and leave only configuration files outside this folder, like class, functions, database connection, etc?
And if it is possible to access the files by url, how would I rewrite these urls in htaccess?
and that all other files should be placed off
Yes, this is good practice. However, you're misunderstanding the implementation.
You can not directly access files outside the document root. But you can indirectly access them. I.e., the web server can't see them, but your programming code can.
Ideally, your site would use the front controller pattern. Here, your index.php file would serve every page of your app by intercepting every request and then routing it to the correct end point. I.e., you would never directly request /contact.php, you'd instead request /contact, which would get funneled to /index.php, which would load the required resources from outside the doc root.
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 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.
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