We have a couple of developers asking for allow_url_fopen to be enabled on our server. What's the norm these days and if libcurl is enabled is there really any good reason to allow?
Environment is: Windows 2003, PHP 5.2.6, FastCGI
I think the answer comes down to how well you trust your developers to use the feature responsibly? Data from a external URL should be treated like any other untrusted input and as long as that is understood, what's the big deal?
The way I see it is that if you treat your developers like children and never let them handle sharp things, then you'll have developers who never learn the responsibility of writing secure code.
You definitely want allow_url_include set to Off, which mitigates many of the risks of allow_url_fopen as well.
But because not all versions of PHP have allow_url_include, best practice for many is to turn off fopen. Like with all features, the reality is that if you don't need it for your application, disable it. If you do need it, the curl module probably can do it better, and refactoring your application to use curl to disable allow_url_fopen may deter the least determined cracker.
It depends on the type of development. If your prototyping then enabling 'allow_url_fopen' is fine however there isn't a significant speed difference between libcurl and file_get_contents and enabling it is only a matter of convenience.
For production servers any call to libcurl should be flagged for a security audit. As should fopen and file_get_contents if 'allow_url_fopen' is enabled. Disabling 'allow_url_fopen' does not prevent exploits it only slightly limits the number of ways they can be done.
Cross-site scripting attacks are a pain, so that's a vote against. And you should absolutely have "allow_url_include" set to off, or you'll be in for a world of hurt.
The big problem is that allow_url_fopen is not more secured, so if you want to save file from a url using curl, you must pass from fopen/file_get to save the file.
CURL is only good to retrieve remote content from URL.
(allow_url_fopen not necessary)
CURL must be added with Fopen or File_get if you want to save remote
file to your server.
(allow_url_fopen obligatory with CURL)
Php must find other ways to make it more secured.
Related
I have a websocket server, implemented using PHP's socket library, and all works well... provided you are using the ws:// protocol.
However, we now need to upgrade the library to work over SSL, i.e. to support the wss:// protocol.
Is it possible to implement wss:// (or more generally, I suppose, SSL connections) using the PHP socket functions, or will we need to rewrite the code to use the stream_socket functions?
(Note that there may be other good reasons to switch to stream_socket, so regardless of the answer we may consider doing that anyway. However, before I spend time evaluating the two options, I want to confirm that sticking with socket is even an option for us.)
I'm submitting an answer on behalf of #BA_Webimax who posted what is probably the correct answer in a comment, but hasn't returned to make that into an answer that I can accept.
So as a direct answer to the question "Is it possible?":
It is possible to do but requires you to implement a lot of things that are already done for you when using stream_socket functions.
-- #BA_Webimax
To flesh that out a bit further, it would mean handling all of the SSL negotiation and encryption manually. This would be a fair amount of work, require a lot of testing and runs the risk of introducing security holes if not implemented exactly right.
Rewriting the code to use the stream_socket functions is likely to be quicker, safer and more robust.
So, whilst the technical answer is yes, it is possible, the pragmatic answer is probably no, it is not.
I've been testing security for some php scripts and have found that, among other things, suhosin strips away a posted variable that is huge... this is fine and desirable, but I'd like for my script to be able to tell that suhosin changed the request.
Does suhosin leave any fingerprints to indicate that some action was taken -- in a way that the script can detect? I'm guessing it can't trigger something like an E_USER_WARNING, because that would be thrown before the script is running and could catch it. Maybe an environment or special global variable?
I tried a few approaches myself, but didn't see anything... perhaps suhosin needs to be configured to do this? I find the suhosin documentation to be, um, difficult to understand.
Yes it does, not fingerprinting, but logging: Suhosin Logging Configuration.
Suhosin's input filter is designed to filter out potentially dangerous payload, e.g. too big requests, transparently. If a script were able to detect this filter and change its program flow based on this information, it would be much easier for an attacker to circumvent the filter.
As a recommendation, filter limits should be set as strict as possible, but as broad as necessary. Your script is supposed to run without being able to detect Suhosin's presence.
Question about PHP safe-mode:
By default it is switched on in PLESK shared-hosting account environment:
While on my site seems to work fine, but maybe it will work faster/better when off?
I dont understand the below text very well, especially PHP's explanation:
PLESK:
By default, PHP is configured to operate in safe mode with functional restrictions. Some web applications may not work properly with safe mode enabled: If an application on a site fails due to safe mode, switch the safe mode off
PHP.net:
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged. The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.
Question1: When/for what reasons should folks turn Safemode ON?
Question2: When/for what reasons should folks keep Safemode OFF?
Turn it off. Always leave it off.
It was designed way back when as a way to make PHP safe to use on mass hosts, and let the hosts "lock down" PHP.
But over time, it was realized that this didn't really work, and didn't really solve the problem anyway. There are better system-level ways of securing servers. So PHP is removing the functionality in the next major version and has it deprecated.
So to directly answer your questions:
When should folks turn it on:
Never. It doesn't really work, and it limits what you can do with PHP in a sane way, so just don't turn it on.
When should folks keep it off:
Always. It doesn't really work, so there's no point to turning it on...
That's my $0.02 anyway...
Edit: Some references
Everything you can do to a server, you can do with Safe Mode on, including: It's possible to write to the webserver anyway. So what's the point?
A mailing list thread from PHP about removing it in 6
Edit2: About speed:
The speed difference is likely to be trivial at best. It's no more than a micro-optimization. You're going to get a far bigger gain by writing your code well than worrying about a specific configuration option such as this. Don't worry about the speed difference at all. Build your application properly, and worry about speed later. Not to mention that the choice of front end web server (Apache, IIS, Lighttpd, NginX, etc) and SAPI (mod_php, CGI, FastCGI, etc) will make a far bigger difference than safe_mode ever can...
Safe mode adds some limits to filesystem-related functions and process handling features (and some totally unrelated cURL options). It's nowadays considered pointless, as it can be circumvented on shared hosting servers by resorting to Perl or Python or bash-CGIs. Professional hosters use suexec and mod_chroot rather.
It can be beneficial if you want to run outdated scripts however (wether that's a good idea is open for discussion). While it doesn't solve all problems, the limitations can help to mitigate risks. It's thus a best effort solution like mod_security.
As far as speed is concerned; it's measureable but not significant.
http://www.php.net/manual/en/features.remote-files.php
The only time I could ever think of doing include("http://someotherserver/foo.php") would be as some sort of weird intra-server service interface, but even then I could think of a million different ways that were safer to accomplish the same thing. Still, my specific question is, has anyone seen remote includes in a production environment and did it make any sense doing so?
Edit:
To clear something up, I would cause physical injury to befall anyone who ever tried to use remote includes in a production environment I worked on... So yes I know this is a nightmarish security hole. Just trying to figure out why its still there versus other weird ideas like magic quotes and global variables.
While I've never seen this in real life, I could imagine a farm with separate physical servers with no shared file system. You could possibly have one server with the all the code ie api.domain.com and the other servers include from it. It would make deployments easier if you have tens or hundreds of sepearate sites. But as alex said, it's asking to be hacked.
Remote file execution is extremely dangerous... I've never used it on my servers, and I can't imagine a valid reason to put your, ahem, balls into the basket that someone else controls. That's just asking to be hacked.
No, I didn't. It's going to the bear's mouth.
I suppose the possiblity to include/require remote files is a consequence of allow_url_fopen -- which was introduced in PHP 4.0.x.
Though, considering the security risks of remote-inclusion, a new directive, allow_url_include was introduced in PHP 5.2 : now, this one determines whether you can remote include/require, while the first ones only impacts fopen and the like -- which is nice : it allows an admin to disable remote inclusion, while keeping remote opening.
As others, I didn't ever see remote-require/include used in real-case scenario, while I, of course, often see situations where remote-opening is used -- bad thing is I sometimes see servers with allow_url_fopen disabled because of security reasons that don't exist anymore :-(
How can I disable the dangerous eval function? Can that be done using ini_set function?
Also how to disable following functions? Can we disable them using ini_set function?
allow_url_fopen
allow_url_include
exec
shell_exec
system
passthru
popen
stream_select
eval is one of the most dangerous function that bad guys can use to exploit the things. There should be a mechanism to disable that without resorting to php.ini file; but is should be done programatically.
Well, guys I am looking for an answers suggesting disabling of these dangerous lovely fellows without going to php.ini file; I mean how to disable them at runtime or programatically?
Thanks in advance....
Update
Has anyone heard about PHP Shell Offender Script? It mainly used the eval function for the exploit. Hackers are able to run their PHP code on your site.
My question was that I don't want to disable the eval function from php.ini file altogether. For example, i have developed my own MVC framework. Now the framework users can specify from frameworks config file whether eval (and others) function should be disabled or not. So this is left to the choice of framework users. Once they specify to disable it; i should be able to disable the eval function programatically.
So that is the scenario. Looking for helpful answers/solutions.
Thanks Again.
Afraid you're pretty much stuck using php.ini to disable most of those. However, it gets worse. eval() is technically not a function, it is a language construct, so it CANNOT be disabled using disable_functions. In order to do that, you would have to install something like Suhosin and disable it from there.
A good webmaster should consider a security review to be an essential part of site setup. Do not try to completely abstract this away, people are lazy enough about security already. If you are going to use tools (like a webhost), you should take the initiative to have at least a cursory knowledge of how to manage one responsibly.
That said, there are some other things you can do to severely cripple most hack attempts, including:
-Disable base64_decode() using disable_functions. Now, there are ways around this, however the vast majority of hack scripts are generic in nature, and this will break about 95% of them as they require the existence of BOTH of these functions in order to operate properly. This does not mean that your server cannot be hacked, but in most cases it would incur the overhead of manually sniffing your server for vulnerabilities, and most hackers are playing the numbers and ain't got time for that (NOTE: some hackers do have time for that, this is not a magic bullet by itself).
-Filter all input for common other exploit string patterns like <?php, which is frequently used to squeak by an opening php tag unnoticed. There are several such patterns. Best practice is to whitelist specific characters and reject all others on a per-input basis. At the very least, filter the aforementioned, null terminators, and possible sql injection strings such as '; -- (do not assume that simply using pdo or mysqli is going to filter ALL injection attempts, there are still some ways to pull this off even if you are properly using prepared statements).
-Any directories that serve only media should have all script access disabled, and all uploads and media should be placed only in such a directory. It is better to whitelist only the acceptable media rather than blacklist scripts, as there are any number of ways to execute a script file (eg: php, php5, phtml, etc) which individually may or may not be available on any given server environment. You can do this with a simple .htaccess placed in the media directory similar to this:
php_flag engine off
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .aspx .htm .html .shtml .sh .cgi
Options -Indexes -ExecCGI
<Files "\.(jpe?g|png|gif|bmp|tiff|swf|flv|mov|avi|mp4)$">
order deny,allow
deny from all
</Files>
This part can be dynamically written by php, so your application would be capable of securing sensitive directories in a manner similar to this, which can mitigate a great deal of hacker pain, as this is typically overlooked. I typically add a similar .htaccess to almost every Wordpress site I work on in the uploads directory, and have often wondered why this is not done out of the box, as it blocks a great deal of hack attempts and does not interfere with the application in any way that I have noticed.
Unfortunately, if you are not on an apache server, you will need to find another solution (on IIS there is most likely an equivalent, but I am not aware of what it would be personally).
-You should also configure your .htaccess (or web.config/etc) to disable any access methods that are not needed for your specific application. If you are not doing RESTful web services, there is really no reason to allow PUT or DELETE, you should almost certainly also disable TRACE, and probably also don't really have any reason to leave OPTIONS or HEAD enabled either. It should also be mentioned that all non-recognized connection methods by default resolve to GET, which means that from the command line I can do something like:
curl -X BOOGITY -d arg=badstuff -d arg2=morebadstuff yoursite.com
In this example, BOOGITY is meaningless, however, your server will interpret this as:
curl -X GET -d arg=badstuff -d arg2=morebadstuff yoursite.com
However your application likely will not.
In order to prevent this, you should configure your server to accept only GET as GET, and not allow it to be the default.
In most cases, the primary point is not to make it difficult to execute specific php patterns in your environment, the point is to prevent the inclusion of rogue code (either locally or externally) so it does not become an issue. If you are allowing the installation of modules or such into your CMS, sloppy programmers WILL eventually create exploits, which you cannot really do much about aside from enforcing pretty stringent API parameters that make it very difficult to do it poorly, but it can never be made impossible. Never underestimate the capacity of an offshore hack shop or self proclaimed "php ninja" to diligently work with your system in the most insecure or non-compliant way possible, create massive vulnerabilities, and to invent any number of roundabout hacks to do so that are actually harder to pull off than just doing it the right way.
/security rant.
To disable functions, mainly for security reasons, you can use the disable_functions directive in your php.ini configuration file.
But, as the documentation states :
This directive must be set in php.ini
For example, you cannot set this in
httpd.conf.
I suppose this is too "internal" to be configurable anywhere else than in PHP... And as it's security related, it's up to the system administrator to configure it.
Still, the best security measure is to write clean/secure code, filter all input, escape all output... And not let anyone run their own code on your server !
In short: you can't do that.
But I think you don't really understand how eval and those functions are exploited. The problem occurs when programmers do not sanitize properly the ARGUMENTS that are passed to them.
The php shell offender script that you mentioned is just a simple PHP script passing arguments to those functions. But the attackers already had a way of injecting/uploading the malicious script. If you are not using these functions at all nor passing arguments from user input, attackers can't run arbitrarily code on your server using eval() or relatives.
Are you going to be hosting this framework for your users? If you are allowing users to upload and run code then you have a bigger problem in your hands.
Read about remote code execution and remote/local file inclusion here to learn more about attacks related to this: Common PHP vulnerabilities
The disable_functions directive is only available in the php.ini configuration.
To disable functions at runtime wouldn't make much sense, since you would be able to modify the disabled function list at runtime to re-enable functions as well.
You can disable eval through https://github.com/mk-j/PHP_diseval_extension and gets around the issue of suhosin not being php7 compatible/stable.
Add this line to your php.ini (you Search for 'disable_functions')
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
Then restart your php service (apache or php-fpm)