I just discovered that under apache a URL like wp-login.php/test might or might not run the wp-login.php script depending on virtual host/ directory settings. This made my code that depended on knowing which "root" script is running by parsing $_SERVER['REQUEST_URI'] unreliable and I am looking to avoid complex string parsing if possible.
Using something like if $_SERVER['SCRIPT_NAME'] == 'wp-login.php' seems to be a better option but can I rely on it to work for all main web servers out there with the various php integration modes (mod_php, fastcgi, cgi)? Is there a better option that I missed?
(for context for people that wonder why I don't just add a define, this is a wordpress core file and I can't and don't want to modify it)
foo.php/bar only works if the AcceptPathInfo-directive (or their pendants on other web servers) has been enabled.
No other configuration has impact to this behavior.
And yes, you can rely on that super-global entry.
I have been working on a project which had been split over several servers and so php scripts had been run through a url interface. e.g. to resize an image I would call a script on one server either from the same or from one of the other servers as
file_get_contents('http://mysite.com/resizeimg.php?img=file.jpg&x=320&y=480');
now, this works but we are upgrading to a new server structure where the code can be on the same machine. So instead of all these wrapper functions I could just include and call a function. My question is: is it worth the overhead of rewriting the code to do this?
I do care about speed, but don't worry about security -- I already I have a password system and certain scripts only accept from certain ips. I also care about the overhead of rewriting code but cleaner more understandable code is also important. What are the trade offs that people see here and ultimately is it worth it to rewrite it?
EDIT: I think that I am going to rewrite it then to include the functions. Does anyone know if it is possible to include between several servers of the same domain? Like if there is a server farm where I have 2-3 servers can I have some basic functionality on one of them that the others can access but no one else could access from the outside?
is it worth the overhead of rewriting the code to do this?
Most likely yes - a HTTP call will always be slower (and more memory intensive) than directly embedding the generating library.
I am using wamp server to develop a website using php, mysql, PDO, html and css.
My wamp server is using PHP 5.3.5, MySQL 5.5.8 and Apache 2.2.17, I am also using InnoDB for transactions.
Considering that my internet hosting provider has at least these versions of php, mysql, apache, and supports InnoDB will the website I build act in the exact same way.
Is it possible to design a website in wamp and then expect several errors when going live? And if so how is this overcome?
Thanks.
As others note, there are many potential hiccups (but I view them as learning opportunities.) But I've done it this way for over five years and have yet to find a difference that wasn't easily overcome. Just stick to the middle of the road, use defaults as much as makes sense, and have fun. It's a great way to explore the platform.
There are many things that can go wrong, most of them having to do with how the web server and PHP are built and configured.
The simplest example is PHP's safe mode: there are many things that safe mode does not allow, and turning it off may not be an option if you are on a shared host. Another example is which extensions are enabled in PHP (your app may require one which the host does not have).
Of course this is all moot if you rent the whole server (or a VM), as in this case you will be able to do whatever you please.
For completeness, I have to mention that there might be platform-specific differences in behavior resulting from the same library (which PHP uses to provide some functionality) compiling into different behavior on different platforms (think platform sniffing in C with #ifdef). I have been bitten by this in the past, but the possibility is not large enough to worry about it beforehand.
A lot of the issues can be worked around by moving constants into config files, like Jon says. Some issues will be less in your control and harder to diagnose. For instance, the output buffer control may be configured differently outside the DocumentRoot you have access to. This can cause confusing problems when you try to write headers out when other content has already been sent out. Similar issues with the timeout numbers, etc.
I would like to host a few 3rd party PHP scripts on a Windows server (running in VMware), so I am looking for a way to limit all the users to accessing their own directories (and subdirectories) and prevent them from executing anything on the machine.
Port 25 is completely blocked and there is a very low limit on the number of external connections they are allowed to make.
There must be others that have come across this issue and any ideas, advice and tips are welcome.Thanks!
For PHP, there's the open_basedir restriction that is supposed to limit PHP script access to certain directories, and it usually does. However, it seems to be flawed. Article here - It's from 2008 though, so the shortcomings described there may have been already addressed in a recent release.
There's also the much hated safe mode that may have its place until PHP 6 comes along (it will be removed there.) be very careful with allowing scripts to execute outside binaries.
Suhosin adds additional security and restriction possibilities to PHP and is certainly a good idea to install. Its defaults may interfere with more complex apps, so be sure to look deeply into its config file. However, it looks like you have to recompile PHP to get it running on Windows. This is something I would really recommend looking into.
If you need something stronger and can use Linux, putting Apache in a chroot jail is something I came across a few days ago. It looks totally advanced, though.
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)