Is there really a way to do this ? Retrieving raw .php file from the server (other than getting into server's FTP account) ? Is this the reason why there are tools/script to encrypt php source code ?
If it's true, then how to protect against it ? (without using php source code encryption)
edit: the server mentioned has php running, eg. apache-php-mysql, your standard hosting server configuration.
If you are talking about someone else's server, then the short answer is no. If third parties could read your PHP source code, that would be quite a security hole, since PHP files tend to contain database passwords, hash keys, proprietary algorithms and other goodies that you don't want falling in the wrong hands.
If you are talking about your own server (ie. that you yourself have access to), then there are simple scripts that you can put on the server, that allow you to specify a path to any file on the server and have it returned as plaintext.
However, you NEVER EVER want to place such a script on a production server, for the reasons mentioned above.
Generally speaking, you can't access remote source code. The PHP module would have to be disabled for this to occur.
But as a thought experiment, how might this happen?
Leaving aside wholesale exploits which get access to the entire filesystem, imagine if there were a security hole in an application which allowed you to insert an line into an .htaccess file. Given that an .htaccess writable by the httpd process is useful for apps like Wordpress, it's not too outlandish a possibility.
If you added this:
php_value engine off
The source files now become downloadable!
It is possible if the server is not well configured that PHP files are not handles as such.
Some examples:
Some servers are configured to show the highlighted source code of a PHP file when requested as .phps instead.
Some developers use .inc for files that are intended to be included using include or require. If the server is not configured to handle these as PHP as well, they will be delivered as plain text when they are requested directly.
But the developer can also be the source of vulnerability. For example when he uses a script for downloading files from the server and this script accepts nearly every input without validation.
If the file is served from a web server that has php interpretation enabled (via HTTP) then it will be processed. The only way you'd receive the code unprocessed is if PHP was disabled somehow.
I have encountered a mis-configured web server in the past that had one virtual host properly setup to server PHP files via the PHP interpreter. There was a second virtual host pointing at the same directory, but didn't have php enabled. This meant things like the 'config.php' for several apps where visible as plain text. As everyone knows a typical config.php has database auth credentials and other things that shouldn't be known.
So, it is very important to understand your web server setup, and make sure you aren't doing something silly.
Related
I'm fairly new to server administration and PHP programming and I've read a few times that under certain circumstances it's possible that a PHP file's source code might be shown in the browser. This is concerning to me, as it would be very bad if that happened on a business website.
Under what circumstances might this happen?
Would putting PHP files above the public_html folder prevent the file from ever being viewed in a browser, eliminating this risk (however it occurs)?
1 . Under what circumstances might this happen?
A: If the server isn't configured to parse .php files (Thanks #MarkBaker for the brevity)
2 . Would putting PHP files above the public_html folder prevent the file from ever being viewed in a browser, eliminating this risk (however it occurs)?
A: No, if your server is configured to use aliases or follow symlinks the files might get accessible again from remote
The only solution is to configure your server in a way that it handles PHP properly - or denies serving files with that extension at all.
So I'm a bit confused about what crafty users can and can't see on a site.
If I have a file with a bunch of php script, the user cant see it just by clicking "view source." But is there a way they can "download" the entire page including the php?
If permission settings should pages be set to, if there is php script that must execute on load but that I dont want anyone to see?
Thanks
2 steps.
Step 1: So long as your PHP is being processed properly this is nothing to worry about...do that.
Step 2: As an insurance measure move the majority of your PHP code outside of the Web server directory and then just include it from the PHP files that are in the directory. PHP will include on the file system and therefore have access to the files, but the Web server will not. On the off chance that the Web server gets messed up and serves your raw PHP code (happened to Facebook at one point), the user won't see anything but a reference to a file they can't access.
PHP files are processed by the server before being sent to your web browser. That is, the actual PHP code, comments, etc. cannot be seen by the client. For someone to access your php files, they have to hack into your server through FTP or SSH or something similar, and you have bigger problems than just your PHP.
It depends entirely on your web server and its configuration. It's the web server's job to take a url and decide whether to run a script or send back a file. Commonly, the suffix of a filename, file's directory, or the file's permission attributes in the filesystem are used to make this decision.
PHP is a server side scripting language that is executed on server. There is no way it can be accessed client side.
If PHP is enabled, and if the programs are well tagged, none of the PHP code will go past your web server. To make things further secure, disable directory browsing, and put an empty index.php or index.html in all the folders.
Ensure that you adhere to secure coding practices too. There are quite a number of articles in the web. Here is one http://www.ibm.com/developerworks/opensource/library/os-php-secure-apps/index.html
I've just had an argument with a colleaque.
My index.php contains my mysql connection and therefor also the host, username, password and database name.
He claims it is a security thread for the possibility exists that the php parser may fail which would cause the webserver to return the entire file as plain text.
I however believe that IF the php parser would fail the webserver would give an internal server error to the users.
Can anyone confirm whether it is or is not a security risk?
thank you.
The short answer is no.
The long answer is yes, but only if:
your server's been compromised, in which case people reading your php files are the least of your worries
you've misconfigured your server to parse .php files and plain text, which would be very silly indeed.
Also, if you're using some kind of version control software, make sure your .hg or .svn or whatever folders can't be viewed from a web browser. You'd be surprised how often that happens.
EDIT:
I would be inclined to go with some of the suggestions on here already, which is what I do in my day to day development. Have a config.php file outside of your web root folder and include this in your index.php. That way you know for sure it's never going to be viewable. Btw, I've been developing in PHP for a number of years and have never had the parser fail in such a way that it's resulted in raw PHP being displayed to an end user.
EDIT 2:
If your colleague is referring to parse errors when he talks about the PHP parser "failing" then in a live environment you should have error reporting disabled anyway.
Either outcome is a possibility. The normal course of action is to use require to bring in a separate file containing your db credentials. That file should be outside the webserver file tree so it can't be reached via a browser.
I'm in the belief that you can never be too safe. What's easier, replacing thousands, possibly millions of records if a hacker gets your db information, the security breach you would have to explain to your users (and possibly their lawyers depending on content and breach) or putting your db information in a separate, password protected folder and including the information on the pages you need the connection?
To me, the choice is simple.
Your co-worker is correct but this is very unlikely to happen. The .php file will only be returned as plain text or as a download if PHP has stopped running on the host.
To be safer, use an include() path to the database credentials in a new folder. In that folder have a .htaccess file with 'deny from all'.
That way even if PHP stops running on the server, Apache will still run and protect all the files including the database credentials. If even apache stops running, the whole webserver will be unreachable and your credentials will still be safe.
:)
Personally I'd put the options in a config file outside the web tree and, once uploaded, remove FTP access from that directory. It's not just a matter of whether the PHP parser fails and drops the file out as plain text BUT if the FTP server has a vulnerability that's compromised that file could be accessed by FTP as well as HTTP.
As long as Apache/PHP is running as a separate user to FTP you can still require the config file from PHP.
imagine that I have two services with the same domain but different hostnames and on different physical computers (for example maps.google.com and mail.google.com). I want to include some php code from one server to the other... how can I do this? (I see a lot of things about how to include across different domains on the same server but this isn't what I want.)
EDIT: I control both of the services that I want to include between but they are on different physical servers under the same domain. It has been suggested that I use a repository and then have each server clone that, so my question is now will I be able to automatically have every server update to the most recent version when changes are made to that repository? I am trying to make a code base of basic functions across the different services.
If you want to include a php file from a remote HTTP server, you will face two issues:
the remote server will interpret its php file, so you will only get a HTML (or any other generated format) stream. It can be bypassed, but you have to access the remote server settings.
it's absolutely NOT safe. If someone changes the remote script, he can do very bad things (like removing files, or even executing system commands)
However, if the remote server let you access the script in its plain text version, you can just include it.
You can't, at least not without exposing your code to the public. If it were possible to read PHP source from any server, that would be a terrible security hole.
If your code definitely isn't sensitive, change its extension so that it's non-executable (say, a .inc file) and include that instead.
I suggest mounting the remote host's directory (examples: NFS (Network File System) for Linux, Windows shares for Windows).
Including (= executing) code over HTTP isn't a good idea since there's no authentication involved.
For example, I have a php script which contains the source code.
I uploaded it to my web server.
For some reason, some attacker could be able to download that file from my web server. They can be able to read and analyze my source code.
So i think this makes interpreted languages (like php ...) not secured vs a compiled language (which contains only binary form).
I want to hear different opinions about this.
Binary isn't secure either. Granted they need to be a bit more of an elite hacker to disassemble it and get the critical algorithm they're after but if someone has access to the binary your algorithm is as good as leaked.
Don't forget binaries can also be reverse engineered that's why they are not secure either. You have to check for server and network level security.
If you're server is set up to handle PHP files, it will compile and execute them prior to sending the output. The actual file will not be downloaded. However, I have seen people name include files with extensions other than *.php, such as *.inc, and they didn't make sure the server would handle those files correctly. This can be dangerous, as include files often contain configuration data.
So, as mentioned by sberry2A, it's all about the server set up rather than the language itself. But, it's certainly something that should have attention paid to it.