I'm trying to obfuscate and speed up my code using Zend OpCache, but OpCache doesn't seem to have the usual functions to store bytecode in a file like other older caching systems did. As OpCache is the native method of caching files in memory in opcode, I'd like to continue using it, but I need to be able to obscure my code in the case of a system breach. (Just another security precaution)
What options do I have available to me to store my PHP files as compiled code in opcode or bytecode?
EDIT: I think people misunderstood what I was looking for for the most part. Please read my comments on the posts. I'm a professional web developer of over 12 years, so I'm not new to this. I just wanted to change my tactics a bit and see if others knew of a way to pull this off that I didn't think of.
It's definitely not a good idea to start developing your own tools for obfuscating or protecting your PHP code.
For protected your code use SourceGuardian or Nu-Coder. Both tools, however, require installing special PHP extension on server, which is not an option for many webhosting companies. These tools provide possibility to lock your code to certain machine (hardware hash, IP binding, ..), control the number of licences, expiration etc.
If you are serious about protecting your code (not only obfuscation) use virtual server + one of the tools mentioned. In run-time, both extensions hold in-memory opcached decrypted low-level code, so besides protecting the code they provide also performance boost. I tested PHP 5.5.x with loaded both SourceGuardian and opcache and there were no conflicts.
Related
I'm currently working on developing a PHP CMF which will eventually be commercially available and I want to use traits. The problem however is that traits are a PHP 5.4 feature and apparently the popular Suhosin security patch isn't compatible with PHP 5.4.
So my question is this: is it safe to run a PHP website without the Suhosin security patch? If not, what vulnerabilities would I be leaving myself and other people using my CMF open to?
Note: I'm not concerned about shared hosting. It's expected that anyone using my CMF would have administrative control over their web server.
Suhosin was a PHP hardening patch. It did not patch any explicit security vulnerabilities -- it merely made some vulnerabilities in PHP scripts more difficult to exploit.
Some of the changes which Suhosin made were eventually rolled into PHP. For instance, Suhosin's various layers of protection against null bytes in inputs were made unnecessary by PHP 5.3.4, which made null bytes in filenames always throw an error (rather than silently truncating the filename at the null byte).
PHP 5.4 is generally regarded to be reasonably safe without Suhosin involved. Going forward, so long as your application supports it, you will be better off with a newer (5.4+) version of PHP, rather than an older version with the Suhosin patch.
If you can't disable eval() (a language construct, not a function) or have a blacklist within eval to disable most of the hacker's toolbox within eval, then you are running a load of bandwidth that is irresistable to hackers looking for bandwidth to run their payloads. What to blacklist, ideally, can't always be done because 3rd party module writers or even framework core depends on some of these functions within an eval() context:
suhosin.executor.eval.blacklist=include,include_once,require,require_once,curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,leak,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,proc_nice,popen,proc_get_status,dl,pcntl_exec,pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair,link,register_shutdown_function,register_tick_function,create_function,passthru,p_open,proc_close,proc_get_status,proc_terminate, allow_url_fopen,allow_url_include,passthru,popen,stream_select
If you can't filter for these functions then a major component of security is missing.
Here are some examples of Remote Administration Tools (RATS) that will infect your site, through any vulnerable 3rd party module or site user account.
RATs can take many forms, some are easy to grep for:
<?php error_reporting(0); eval(gzuncompress(base64_decode('eF5Tcffxd3 ...
<?php preg_replace("/.*/e","\x65\x76\x61\x6C\x28\ ...
Some are more professional and obfuscated, and cannot really be grepped for, and cannot be found unless suhosin tips you off that they executed:
<?php $_0f4f6b="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";$_0f4f6b("\x7 ...
<?php require "./.cache/.%D59C%49AA%73A8%63A1%9159%0441"; ?>
(note in this case the CACHE directory cannot be in source control, therefore cannot be tracked either)
IMHO, the statement above from duskwuff, that things would be fine without Suhosin is neither authoritative nor necessarily correct (especially given the amount of critical holes newer PHP versions have seen since then).
To my mind, it would be definitely better - from a security POV - if Suhosin was available for current PHP version.
Of course, as it is not, staying at old (eventually unmaintained) versions of PHP isn't a solution either.
Generally PHP and especially PHP applications are notoriously known for having security issues... so the question is less "are newer PHP versions safe without Suhosin"...
I'm currently working on developing a PHP CMF which will eventually be commercially available and I want to use traits. The problem however is that traits are a PHP 5.4 feature and apparently the popular Suhosin security patch isn't compatible with PHP 5.4.
So my question is this: is it safe to run a PHP website without the Suhosin security patch? If not, what vulnerabilities would I be leaving myself and other people using my CMF open to?
Note: I'm not concerned about shared hosting. It's expected that anyone using my CMF would have administrative control over their web server.
Suhosin was a PHP hardening patch. It did not patch any explicit security vulnerabilities -- it merely made some vulnerabilities in PHP scripts more difficult to exploit.
Some of the changes which Suhosin made were eventually rolled into PHP. For instance, Suhosin's various layers of protection against null bytes in inputs were made unnecessary by PHP 5.3.4, which made null bytes in filenames always throw an error (rather than silently truncating the filename at the null byte).
PHP 5.4 is generally regarded to be reasonably safe without Suhosin involved. Going forward, so long as your application supports it, you will be better off with a newer (5.4+) version of PHP, rather than an older version with the Suhosin patch.
If you can't disable eval() (a language construct, not a function) or have a blacklist within eval to disable most of the hacker's toolbox within eval, then you are running a load of bandwidth that is irresistable to hackers looking for bandwidth to run their payloads. What to blacklist, ideally, can't always be done because 3rd party module writers or even framework core depends on some of these functions within an eval() context:
suhosin.executor.eval.blacklist=include,include_once,require,require_once,curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,leak,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,proc_nice,popen,proc_get_status,dl,pcntl_exec,pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair,link,register_shutdown_function,register_tick_function,create_function,passthru,p_open,proc_close,proc_get_status,proc_terminate, allow_url_fopen,allow_url_include,passthru,popen,stream_select
If you can't filter for these functions then a major component of security is missing.
Here are some examples of Remote Administration Tools (RATS) that will infect your site, through any vulnerable 3rd party module or site user account.
RATs can take many forms, some are easy to grep for:
<?php error_reporting(0); eval(gzuncompress(base64_decode('eF5Tcffxd3 ...
<?php preg_replace("/.*/e","\x65\x76\x61\x6C\x28\ ...
Some are more professional and obfuscated, and cannot really be grepped for, and cannot be found unless suhosin tips you off that they executed:
<?php $_0f4f6b="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";$_0f4f6b("\x7 ...
<?php require "./.cache/.%D59C%49AA%73A8%63A1%9159%0441"; ?>
(note in this case the CACHE directory cannot be in source control, therefore cannot be tracked either)
IMHO, the statement above from duskwuff, that things would be fine without Suhosin is neither authoritative nor necessarily correct (especially given the amount of critical holes newer PHP versions have seen since then).
To my mind, it would be definitely better - from a security POV - if Suhosin was available for current PHP version.
Of course, as it is not, staying at old (eventually unmaintained) versions of PHP isn't a solution either.
Generally PHP and especially PHP applications are notoriously known for having security issues... so the question is less "are newer PHP versions safe without Suhosin"...
I'm looking to protect small parts of my source code from being read when it is installed in other servers. Our created software consists of an engine, which is entirely copyrighted and an open source UI layer, which is released as open source.
That engine works with many API calls to our central server and is encrypted, but if source code of the engine can be read then that causes problems for data integrity when information is sent or received from central server. As a result we need the engine source code to be both fast and not readable.
I know that APC can cache bytecode and is very fast, but can I somehow convert the source code to bytecode and release it that way directly, without needing APC? As in, convert PHP source code to bytecode without requiring to install additional extensions to the other server?
I'm not looking for software such as IonCube or Zend Guard or any obfuscators.
Any help would be appreciated, I read through a handful threads here about compilers and obfuscators, but nothing that seemed to be the solution.
You could use apc_bin_dumpfile to store your files' generated bytecode and then redistribute it. Other platforms must have apc installed to be able to read it using apc_bin_loadfile.
You could also try compiling your code as a php extension using phc
I have a server which consists of several Zend Framework application.
I want to know if it is a good idea to upload Zend Library on the server and share it among all the applications instead of uploading it per application.
Does it influence speed if for example multiple applications request a library simultaneously or not.
What is its Pros and Cons?
Thx in advance.
My answer applies in general to shared libraries, as this should not be specific to Zend Library:
PROS of sharing:
Less disk space usage
Possibly less memory usage (depends on many factors, including OS)
Update once, update all (you do not have to update the library for every single app
CONS of sharing:
If you need a particular version of the library for a certain application (for compatibility reasons for example), you cannot do it by sharing the library
Risk of breaking apps by updating to an incompatible library version.
As others have pointed out, there are pros and cons. The big con is that every time you're going to upgrade your library code, you need to test every application, not just the one that needs the upgrade right now.
The big pro is that if you're using an opcode cache like APC (and you should be), you're wasting a fair bit of memory loading identical chunks of library code. Depending on the size of your opcode cache, and how much of the library code actually ever gets run, this could become an issue at some point. If the size of your opcode cache is not big enough to hold everything, you'll end up with a performance hit of some magnitude.
A middle-ground solution is to keep all your libraries some place on the server where they can be shared. Build your apps to use some configuration value for loading.
APP1: config.php
<?PHP
define('ZEND_LIB_PATH','/path/to/ZendFramework-1.9/library');
set_include_path(ZEND_LIB_PATH . PATH_SEPERATOR . get_include_path());
APP2: config.php
define('ZEND_LIB_PATH','/path/to/ZendFramework-1.10.1/library');
set_include_path(ZEND_LIB_PATH . PATH_SEPERATOR . get_include_path());
That way if two apps happen to be using the same version, they can share opcode caches for that version, but you're not tied to it.
DISCLAIMER: I haven't actually done this, so you probably want to test the theory before putting it into practice.
If the applications are separate, I would give each one its own library to avoid issues when you need to upgrade a library on one of the apps, but don't want to have to test and update them all with that library version.
Then again, if those applications share code, they should definitely share the libraries too, to avoid even worse problems with the shared code running under different library version on each site.
A friend has recommended that I install php APC, claiming it will help php run faster and use less memory
sounds promising but I'm a little nervous about adding it to my VPS server
I have one small app that I've built using codeigniter, and several sites that use the popular slideshowpro photo gallery software
could install this break any of the back end code on my sites?
I'm no high tech server guy, but should I give this a try?
Depends entirely on your situation.
Is your site unresponsive or slow at the moment? Is this definitely due to the PHP scripts and not any other data sources such as a database or remote API?
If you answered yes to the above, then installing one of the many PHP accelerators out there would be a good shout. As for using less memory, that's largely dependent on your apache/lightppd/nginx config and php.ini variables.
Most PHP accelerators work by converting the (to be) interpreted PHP code into opcode. This is then stored in memory (RAM) for fast access. If you haven't already implemented file-based caching in CodeIgniter then the benefits of installing a PHP accelerator would be noticeable. If you haven't, then I suggest you do that first before moving straight over to (wasting?) spending time trying to install APC manually.
If your site is currently performing well and you're not too confident in your *nix skills then I suggest you try implementing CodeIgniter caching first rather than try messing with what is an already working VPS.
My personal preference is PHP eAccelerator.
Should installing a PHP cache engine not improve your site's performance then I suggest you look at what other factors influence your application. As stated above, these could be: database or API to name a few.
Hope this helps.
APC is basically a cache engine that stores your compiled php scripts on a temp location on your server. Meaning that these do not have to be interpreted every time someone calls your sccript. It is a PHP extension can can safely be turned ON or OFF and it does not affect your actual code. So... do not fear!
When a php script is processed, there is a compilation phase, where php converts the source code of the php files into "opcodes". APC simply caches the result of this compilation phase, so it should be safe to turn on.
That said, when making such changes to production code it is always wise to run a regression test to ensure no new issues have been introduced.