Is there a way block access to includes?
Moderator: General Moderators
Is there a way block access to includes?
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?
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?
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
One of the things I like to do is place my includes in a .php file and "secure" them with a definition check.
Then in the calling page add...
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.
Code: Select all
if (!defined('OK_TO_SHOW'))
{
die("This page is NOT ok for you to see.");
}Code: Select all
define('OK_TO_SHOW', true);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.
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.
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.
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:
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.
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>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.aqh2 wrote:Is there a way that I can hide my MySql login or password?
I think you mean "above" and "document" there. :-)AGISB wrote:If possible place the files below the directory root.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
To be quite honest, I would rather handle my class definitions like this:
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.
Code: Select all
/public_html/classes/Story.phpBut that's just me, and I know that legacy code can have some of these restrictions.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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?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.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.
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.
No, executing code out of context is dangerous, sometimes more so than exposing the source.AGISB wrote:Making sure that the includes are parsed is the first important step.
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.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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...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.
- 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).
.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.Making sure that the includes are parsed is the first important step.
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...
If only in a pefect world, all developers could exist...
My original comment might be clearer:Which poor suggestions?
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.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.
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.
I don't recall recommending an approach that requires either. Was this statement directed at someone else?Assuming a user can both edit http.conf and php.ini is a little out there.
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.The second prevents execution out of context (assuming the include should be tied to parent files).
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.They are "poor" if you have a dedicated server and can hack everything in sight to your heart's content.