I have a doubt about PHP, Apache, server interpretation... I know that when a PHP file is loaded by the browser from an Apache+PHP server it is interpreted and only the HTML and plain text is showed but is there a way to download this files instead of interpreting them?
In this case it would be very unsecure because MySQL passwords would be unsafe.
Is it any security measure to prevent this or it's impossible to download this files?
As long as your server is setup properly it isn't going to happen.
A good step though is to put all of your actual passwords and whatnot in a config.php and including it. That way you can use htacces too block that file so that should your server ever start serving the raw pages that file won't be accessible anyway.
To clarify if you create a .htaccess file and place it in the same folder as the config.php with the below information that file will not be served, even if requested directly. Simply define your config stuff (db name, user name, password, hashes, etc) in this file and include_once it at the top of each page that needs it and you will be good to go.
<files config.php>
order allow,deny
deny from all
</files>
There is no way to 'download' PHP files, but for more security you can place your 'core' PHP files outsite of the public_html folder
Unless the PHP interpreter stops working for some reason, it's not something to worry about. Most servers are designed to interpret the PHP files every time they are requested and serve only the interpreted HTML text. It's possible to secure your sensitive PHP settings files just in case - often by placing them outside of the root directory with modified permissions.
The only way someone could download the files is to have a server set up that serves the raw files. As long as you don't have such a server set up, they're inaccessible. If the only server software on your system is Apache and it's configured correctly, people cannot see your source code.
However, if somebody seeing your source would render your app vulnerable, you might want to give some thought as to how you can fix that problem. Lots of secure open-source software exists — why would yours being open-source cause problems?
With proper configuration apache guarantees that files will always get interpreted and won't be offered for download.
You always may install fault update or make wrong configuration, but with skilled admin and stable release those cases just don't happen.
Related
I'm currently developing a PHP framework. Other developers may create modules for the framework. Source code of these modules should reside in the framework directory.
Since the project is open-source, modules know location of the config file which has database password in it. How to protect passwords from malicious modules? Please check that modules may just require_once the config file and do harmful things!
Currently I'm storing Database passwords in a directory named config, and protecting it by a .htaccess file:
<Directory config>
order allow,deny
deny from all
<Directory>
But that is not sufficient to prevent scripts steal the password, is it?
I've read the thread How to secure database passwords in PHP? but it did not help me finding the answer.
In PHP, you can't. It's not a sandboxed language; any code you run gets all the permissions of the user it's running under. It can read and write files, execute commands, make network connections, and so on, You must absolutely trust any code you're bringing in to your project to behave well.
If you need security boundaries, you would have to implement them yourself through privilege separation. Have each module run in its own process, as a user with very low privileges. Then you need some sort of inter-process communication. That could be using OS-level pipes, or by having separate .php files run as different users running as web services accessed by the user-facing scripts. Either way, it doesn't fit neatly into the usual way PHP applications work.
Or use another language such as Java, which can offer restricted code with stronger guarantees about what it is allowed to do (see SecurityManager et al).
Unfortunately, PHP is not a very secure language or runtime. However, the best way to secure this sort of information is to provide a configuration setting that has your username/password in it, outside of your document root. In addition, the modules should just use your API to get a database connection, not create one of their own based on this file. The config setting should not be global. You should design something like this in a very OOP style and provide the necessary level of encapsulation to block unwarranted access.
I've got an idea that may work for you, but it all really depends on what abilities your framework scripts have. For my idea to be plausible security wise you need to essentially create a sandbox for your framework files.
One idea:
What you could do (but probably more resource intensive) is read each module like you would a text file.
Then you need to identify everywhere that reads a file within their script. You've got things like fopen for file_get_contents to consider. One thing I'd probably do is tell the users they may only read and write files using file_get_contents and file_put_contents, then use a tool to strip out any other file write/read functions from their script (like fopen).
Then write your own function to replace file_get_contents and file_put_contents, make their script use your function rather than PHP's file_get_contents and file_put_contents. In your file_get_contents function you're essentially going to be checking permissions; are they accessing your config file, yes or no, then return a string saying "access denied" if they are or you use the real file_get_contents to read and return the file if not.
As for your file_put_contents, you just need to make sure they're not writing files to your server (they shouldn't be allowed, imagine what they could do!), alternatively, you could probably use a CHMOD to stop that happening.
Once you've essentially rewritten the module in memory, to be secure, you then use the "exec" function to execute it.
This would take a considerable amount of work - but it's the only pure PHP way I can think of.
I am not sure if it is possible, however you could maybe make a system which checks the files in the module for any php code which tries to include the config file, and then warn the user about it before installing.
However it really shouldn't be your responsibility in the end.
A very good question with no good answer that I know of, however...
Have you seen runkit? It allows for sandboxing in PHP.
The official version apparently isn't well maintained any more, however there is a version on GitHub that is quite popular: zenovich/runkit on GitHub
Although the best solution is perhaps a community repository where every submission is checked for security issues before being given the OK to use.
Good Luck with your project
Well, I see no problem here.
If it's a module, it can do harmful things by definition, with or without database access. It can delete files, read cookies, etc etc.
So, you have to either trust to these modules (may be after reviewing them) or refuse to use modules at all.
Don't include your actual config file in your open source project.
The way I do it is a create just the template config file config.ini.dist
When a user downloads your project they have to rename it to config.ini and enter their own configuration information.
This way every user will have their own database connection info like username and password. Also when you update your project and users download your newest version, their own config files will not be overwritten by the one from your program.
This a a very common way to store configuration in open source projects - you distribute a template config file and tell users that they have to rename it and enter their own configuration details.
I don't think there is a way to prevent a module to capture sensible data from the actual framework configuration and send it to some stranger out there. On the other end, I don't think that should be your responsability to protect the user from that to happen.
After all, it's the user that will decide to install any module, right? In theory it should be him that would have to verify the module intents.
Drupal, for example, does nothing in this direction.
There is a worst problem, anyway: what'd prevent a nasty module to wipe out your entire database, once it is installed?
And, by the way, what could the malicious stranger do with your database password? At the very least you anyway need to secure the connection of the database, so that only trusted hosts can connect to the database server (IP/host based check, for example).
I am always reading that you should always store your database credentials outside of your document root because normally you would have them set to db.inc or something similar.
I can understand this and naturally it makes perfect sense.
What I don't understand is why you are making the file into one that you either need to set apache to hide or you need to put it into a secure location in the first place.
What is the issue with making it, say db.php - Then apache knows to execute the script first and return the output (which would presumably be blank in most cases).
Maybe I am being dumb and missing an inherent security flaw but is there any issues with just storing your details in a .php file? I mean Wordpress and other major open source PHP applications manage to get away with it, but is this because they can't make their script talk to folders outside of www or because it is just as secure as any other method?
Maybe I am being dumb and missing an inherent security flaw but is there any issues with just storing your details in a .php file?
A tiny slip up in the configuration of Apache, and the file starts being served raw instead of being processed by the PHP engine.
I mean Wordpress and other major open source PHP applications manage to get away with it, but is this because they can't make their script talk to folders outside of www or because it is just as secure as any other method?
They accept increased risk for increased convenience.
Storing files containing (database) credentials outside the document root is always a good idea.
Say, you upgrade Apache, but forget updating the configuration with PHP. Any file in the document root can possibly be downloaded without getting parsed.
Wordpress, Joomla, phpBB and others are made to be portable. That is, reside in one folder.
Is it possible to somehow view another websites php files/codes?
Or to rephrase the question, Can my php codes be viewed by anybody except for those who have access to the file?
If so, how can I best prevent this?
Ps: Server OS is Ubuntu 9.10 and PHP version is 5+ (Apache2)
A bug or security vulnerability in the server (either Apache or the PHP engine), or your own PHP code, might allow an attacker to obtain access to your code.
For instance if you have a PHP script to allow people to download files, and an attacker can trick this script into download some of your PHP files, then your code can be leaked.
Since it's impossible to eliminate all bugs from the software you're using, if someone really wants to steal your code, and they have enough resources, there's a reasonable chance they'll be able to.
However, as long as you keep your server up-to-date, someone with casual interest is not able to see the PHP source unless there are some obvious security vulnerabilities in your code.
Read the Security section of the PHP manual as a starting point to keeping your code safe.
By using exploits or on badly configured servers it could be possible to download your PHP source. You could however either obfuscate and/or encrypt your code (using Zend Guard, Ioncube or a similar app) if you want to make sure your source will not be readable (to be accurate, obfuscation by itself could be reversed given enough time/resources, but I haven't found an IonCube or Zend Guard decryptor yet...).
Noone cand read the file except for those who have access to the file. You must make the code readable (but not writable) by the web server. If the php code handler is running properly you can't read it by requesting by name from the web server.
If someone compromises your server you are at risk. Ensure that the web server can only write to locations it absolutely needs to. There are a few locations under /var which should be properly configured by your distribution. They should not be accessible over the web. /var/www should not be writable, but may contain subdirectories written to by the web server for dynamic content. Code handlers should be disabled for these.
Ensure you don't do anything in your php code which can lead to code injection. The other risk is directory traversal using paths containing .. or begining with /. Apache should already be patched to prevent this when it is handling paths. However, when it runs code, including php, it does not control the paths. Avoid anything that allows the web client to pass a file path.
Why is it a good practice to remove PHP files from the htdocs/public directory?
They are being parsed anyway, right?
if PHP files are at some point not parsed due to a configuration error or, say, a failing interpreter, there is no danger of the source code (and possibly passwords) being revealed to the world as clear text.
Also, human mistakes like renaming a .php file to .php.bak are less dangerous that way.
I had this once, years ago, when a colleague, from the Perl world and totally ignorant about PHP, decided to set "short_open_tags" to "off" on a server we shared, because short_open_tags messed with some XML experiment he had going (<?xml version="1.0"?>). That was fun! :)
and a second thing:
Calling includes out of context
Having includes (i.e. pieces of PHP code that is included elsewhere) under the web root makes you potentially vulnerable to people calling those includes directly, out of context, possibly bypassing security checks and initializations.
If you can't/won't avoid PHP code to reside in the web root, at least be sure to start each file checking whether it is running in the correct context.
Set this in your main script(s):
define ("RUNNING_IN_SCRIPT", true);
and add this to the 1st line of each include:
if (!defined("RUNNING_IN_SCRIPT")) die ("This file cannot be called directly.");
Yes, they are parsed. However, that is completely dependent on you or the server admin not screwing up the config files.
All it takes is a quick typo in the Apache config before Apache forgets to parse the PHP (I've had this happen). Since Apache won't know what to do with a PHP file after that, your source code just gets output as plain text, and can be immediately copied. Heck, it's even cached in the user's browser, so a malicious user can quickly copy all your code and browse it later at their convenience, looking for security holes.
You don't want your source to be visible even for a second. If you have no code files in the htdocs directory, this can't happen. They can easily be included into your code from outside the directory however.
Many MVC frameworks use this method of sandboxing for just this purpose.
The more executable PHP files you have, the more security risks you also have :
What if there is a problem in your configuration (it happens !), and the source code of your PHP file containing your database credentials is sent to the browser ?
what if there is some "bad" thing left in one of those files, you didn't think about, and no-one ever tested ?
The less PHP executable files you have... well, that's a couple of potential problems you don't have to care about.
That's why it's often considered as best to :
put under the document root only the PHP files that have to be called via Apache (like index.php, for instance),
and put outside of the document root the PHP files that are not accessed directly, but only included by the first ones (ie, libraries / frameworks, for instance).
My friend asked me to update a PHP application that his company uses. I found out that the application uses .ini extension for DB configuration file. The file contains DB host address, username, and password!!. The problem is that I can access the file on web-browsers.
I am trying to understand why. Is there any particular reasons to use a regular php file with .ini extension??? I just don't get it.
Readability is one of the main reasons I've used ini filies for php script configs in the past. People who are not coders have run into an ini file at least once before, and can understand what it is much easier than even a simple php file.
The issue of ini files being readable by everyone can be prevented by server side configuration, or even better, by simply adding a single line of code inside a comment line at the top of the file.
That way php will output an 'Direct access forbidden' when the file is accessed via a browser, and the ini file will continue to function as before.
You can use Zend_Config_Ini. It is comfortable and easy. Just simply do not put config files where any user can reach them (for example public_html).
INI files are just one way of dealing with configuration, perhaps the developer came from a Windows-developing background and used whatever he was familiar with :). Besides, PHP offers a convenient way of parsing INI files through the parse_ini_file function.
You'll want to make sure the .INI file is not accessible from the web though. Move it below the docroot so your PHP script can still access it, but random browsers cannot.
For what it's worth, PHP has traditionally used php.ini to configure PHP. So maybe it's some kind of legacy thing?
Seems like this is just former programmer's wish to use different file type for configuration. If there is no other uses for this file, rename it to *.php and forget it. If not, configure webserver to parse ini as php or, better, move it to directory, not reachable from web-server.