Is there a way block access to includes?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
aqh2
Forum Newbie
Posts: 2
Joined: Sat Nov 19, 2005 7:50 am

Is there a way block access to includes?

Post by aqh2 »

Hi,

I work on a Unix platform with AFS. I use afs permissions to block access to user 'http'. I found that if I access my .inc file directly, all the content in clear php script is displayed.

If I set permissions to user "http" to none to the file directory with the includes, my pages stop displaying. I will need to give the user read permission in order for it to work, but that is not good because I have my mySQL password there.

Is there a way that I can hide my MySql login or password?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Its being read as plain text - apparently. Try adding a PHP file extension if a PHP file, or if there are no requestable files in the directory (by URI), maybe add a "deny from all" to a .htaccess file.
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

One of the things I like to do is place my includes in a .php file and "secure" them with a definition check.

Code: Select all

if (!defined('OK_TO_SHOW'))
{
    die("This page is NOT ok for you to see.");
}
Then in the calling page add...

Code: Select all

define('OK_TO_SHOW', true);
What this does is allows the PHP script to run through the PHP engine and if the evaluation fails, throw a die error.

NOTE: This is not security for your files. This merely keeps your .php scripts from showing as text or executing when not being called from another file.
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

1. name the files .php or add .inc to the apache conf file and connect it to php

2. if possible place the files above the document root. On UNIX systems just crete an inc folder in the folder your htdocs dir is in.
Last edited by AGISB on Sun Nov 20, 2005 1:27 am, edited 2 times in total.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

Just place your includes above document root. Every other "solution" addresses a symptom rather than the root cause of the problem.

If your particular situation prevents this for some reason, you can deny requests for all .inc resources:

Code: Select all

<Files ~ "\.inc$">
    Order allow,deny
    Deny from all
</Files>
Be very careful with some of the common recommendations such as naming includes with a .php extension or instructing Apache to parse .inc files as PHP. If you take any of these approaches, you introduce new security risks, and you need to take additional measures such as what Everah suggested to mitigate those risks.
aqh2 wrote:Is there a way that I can hide my MySql login or password?
Unless you're on a shared host, keeping sensitive information out of document root is good enough for most cases. It pushes the responsibility to your server's security.
AGISB wrote:If possible place the files below the directory root.
I think you mean "above" and "document" there. :-)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

To be quite honest, I would rather handle my class definitions like this:

Code: Select all

/public_html/classes/Story.php
So that when any file is included, there is no code "run" persay, just a bunch of definitions. All includes should be able to be run like require_once() and not break anything. Personally, I think require() is a code smell.

But that's just me, and I know that legacy code can have some of these restrictions.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

Ambush Commander wrote:To be quite honest, I would rather handle my class definitions like this
Just be careful when offering advice about class definitions to answer a question that's not about class definitions. :-)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Be very careful with some of the common recommendations such as naming includes with a .php extension or instructing Apache to parse .inc files as PHP. If you take any of these approaches, you introduce new security risks, and you need to take additional measures such as what Everah suggested to mitigate those risks.
Just noting not everyone can move stuff above doc root... Often there is no other alternative but to simply "deny from all" or use a PHP extension (alternatives to Apache...), et al. They may address symptoms, but the alternatives can be pretty limited - how many folk own dedicated servers again? ;)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

If puting above the docroot is not an option, then create a sub-dir and create a .htaccess file with the same entry as shiflet posted.

(If your server is using Apache that is.)
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

shiflett wrote: Be very careful with some of the common recommendations such as naming includes with a .php extension or instructing Apache to parse .inc files as PHP. If you take any of these approaches, you introduce new security risks, and you need to take additional measures such as what Everah suggested to mitigate those risks.
Making sure that the includes are parsed is the first important step. As you always should limit access to only those who should get it you are not really putting in new security risks but limiting a lot of others.

I agree that it is not the only security measure to take but to warn people that this might be a bad approach is kind of dangerous. PHP code no matter if included or in the main script should always be parsed.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

AGISB wrote:Making sure that the includes are parsed is the first important step.
No, executing code out of context is dangerous, sometimes more so than exposing the source.

My statement is intended to highlight the fact that "solutions" that address a symptom are not sufficient. Always address the root cause of the problem, then you can consider Defense in Depth measures.

It is not dangerous for me to highlight additional risks that are accrued when poor suggestions are followed. It would be negligible for me to do otherwise.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

It is not dangerous for me to highlight additional risks that are accrued when poor suggestions are followed. It would be negligible for me to do otherwise.
Which poor suggestions? Its difficult to apply root solutions in this particular case. Assuming a user can both edit http.conf and php.ini is a little out there. And many web apps do not require moving of includes above docroot. Since its therefore nigh impossible for many users to apply the proper measure, they have little choice but to fall back on those poor suggestions... I'd argue they're basic standard security measures at large - unless you have a dedicated host, or access to configuration files...

- Ensuring files containing php are parsed (esp. if containing credentials of some form, or a closed source app) - usually by adding .php
- Adding a check to ensure only a parent script will lead to actual usage of an include (the define check)
- Use of .htaccess "deny from all" directives

There are others...

But which exactly are poor? The first will prevent plain text reading (in the absence of Apache, in the absence of other server controls). The second prevents execution out of context (assuming the include should be tied to parent files). Third prevents all access (assuming Apache is used).
Making sure that the includes are parsed is the first important step.
.php = parsed, .inc = plain text - if on a shared host, no php.ini access, etc. Which is a very common scenario. Executing code out of context is bad, but having an include that can be executed in the first place (capable of an action) is simple negligence from the developer...IMO. There's also the "no-Apache" scenario.

Overall, I agree with what you're saying. But it just seems very narrow. Telling users these are "poor" is misleading. They are "poor" if you have a dedicated server and can hack everything in sight to your heart's content. We're not all so lucky however...;) We don't all use Apache. We can't all move things above docroot.

If only in a pefect world, all developers could exist...
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

Which poor suggestions?
My original comment might be clearer:
Be very careful with some of the common recommendations such as naming includes with a .php extension or instructing Apache to parse .inc files as PHP. If you take any of these approaches, you introduce new security risks, and you need to take additional measures such as what Everah suggested to mitigate those risks.
The comment immediately before mine lists two suggestions, and the first one is not ideal. If I were new to this topic, I would interpret the first one as being the preferred solution, based on the order and phrasing of the two.

I felt obligated to point out the additional risks associated with these types of approaches (and I tried, perhaps unsuccessfully, not to point fingers at specific comments) as well as mention how these additional risks can be mitigated.
Assuming a user can both edit http.conf and php.ini is a little out there.
I don't recall recommending an approach that requires either. Was this statement directed at someone else?
The second prevents execution out of context (assuming the include should be tied to parent files).
Yes, and it's important that this always be coupled with any recommendation to execute that code. In other words, we should be careful not to recommend that people configure their includes to be executed and fail to tell them how to prevent the execution of those includes out of context.
They are "poor" if you have a dedicated server and can hack everything in sight to your heart's content.
If you're on a shared host, even includes stored outside of document root are at risk. The only exception is if each host is sandboxed, but this is quite rare, unfortunately.
Post Reply