I am curious about the security of PHP on an HTML webpage where PHP code is embedded (a webpage that would exist on the server as "webpage.php") or on a PHP script that may be referenced by an HTML page (that is, a PHP script that is not actually part of a webpage that exists on the server as "something.php" and is referenced by "webpage.html"). Getting to the point, let us say that if the source code of my PHP script is known by anyone it would be a very big problem. I know that when you view the source of a PHP page in a browser the PHP script is not shown, but what if the PHP server failed and the HTML still loaded (is this even possible), would a user be able to see the PHP script? To be more general, is there ANY possible way that a user could access the source of a PHP script from a web browser, and if so, how do I prevent it?
what if the PHP server failed and the HTML still loaded (is this even possible), would a user be able to see the PHP script?
Security holes aside, this typically happens when someone's messing with the server or migrating the site across servers and the PHP files have been dumped into a folder that's not set up to execute PHP. This is the price you pay for PHP deployment being as simple as dropping files into a folder.
Whilst it's never ideal to leak PHP source, you can mitigate the situation by putting all your sensitive deployment information (like database passwords) in a PHP include file that lives outside the web root (the folder mapped to the / URL, often known as htdocs). It's much harder to screw up the configuration to leak that.
(For larger, more modular projects you will typically be doing the bulk of your processing work in includes anyway.)
One simple thing you can do to guard against a simple server mis-configuration is to have the HTML file include a PHP file which is outside of the document root (at or above the level of the document root, usually "htdocs"). That way if there was a brief misconfiguration all the user would get would be the path to the included file, but they would not be able to load that included file directly in their browser.
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.
I'm doing a security audit on my friend's website. One piece of functionality is allowing users to upload files from html. The only validation is renaming the file to the current time stamp.
I was wondering, is there a way to upload a malicious file so that when a user goes to the url for that file, it executes code (on the server side)?
I tried uploading a hello-world php script, but it simply displays the code rather than executing it. If the file extension was .php, it would be executed, however, there is no file extension (because the file was renamed).
EDIT: I have access to the complete source code as part of the security audit. It would be better if I could solve this issue without using it, but I can answer any questions about the source code if needed.
As far as i know, uploading the file and visiting it via. the browser can not execute it server-side, unless the server is set to execute files without extensions.
However, if there's other vulnerabilities like Local File Inclusion you might be able to upload and execute a php script.
You can read a bit about File inclution here:
Wiki on RFI (almost the same) and here
Document on LFI and how it can be used
If you can execute the file or not depends allot on the server/sites setup, so you'll have to pen-test it you self to se if you can execute a php script.
The only thing you can do in a file with no extension is, as you mention your self, XSS, but only in older browsers (IE8 and down is vulnerable, most other browsers aren't.)
The security scanner Chorizo! might be of interest:
https://chorizo-scanner.com/
The solution was implemented by a company, which does daytime PHP consulting and coding.
It's a payed service. One scan is free.
Well, one thing that you would always remain at risk for is providing the possibility of getting malicious code onto the server - whether or not they would be able to execute it merely by viewing the URL of the specific file isn't all you have to think about.
If there was a vulnerability in YOUR code where you dynamically include or open local files on the server, then one could simply include the (now) local malicious code to be executed. Now granted this sort of attack is even common with people trying to include code on remote servers, but some setups are configured to prevent including remote files which would stop those attacks. Such a configuration would still leave you vulnerable if the code is physically on the machine and a weakness is found in your executable code.
That's just a thought - I wouldn't worry or panic too much about it, but I wouldn't entirely rule it out either.
From my understanding a lot of web output relies on reading files not actually executing them. A server will need specific permissions to execute a file.
The solution is firstly to check that the file types uploaded are allowed. If you are only uploading images - you don't expect a .php script. But this does not stop me creating bad.php and uploading it as bad.jpg.
I for example (on my ubuntu box) uploaded a php file with 777 permissions and could only run it by typing php hello.php. You would never normally do an include() on a file someone has uploaded so I believe most code relates to being readable.
Wikipedias page on File inclusion is a good start and includes a PHP example:
https://en.wikipedia.org/wiki/File_inclusion_vulnerability
Upload a file with javascript. There are plenty of js vulnerabilities.
http://en.wikipedia.org/wiki/Cross-site_scripting
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.