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.
Related
I'm thinking of protecting my script to the mass majority of users (non-web dev savvy) and I came across an online service to encode php script. I'm not sure about it though.
Is it safe to encrypt php script? What if the encoded code has something fishy in it?
If you intend to distribute the PHP file then I would suggest that you do not do this. It's only going to irritate those that want to tinker with it.
If for some reason you don't want them tinkering with it, then don't distribute the PHP file.
If you need to distribute the file AND you don't want them tinkering with it, then I would highly suggest you not do this in PHP and instead write the functionality using C as an extension to PHP.
You'll notice that at no point do I suggest you actually go ahead and "encode" the php file. That's not going to buy you anything.
If you are looking to obfuscate your server-side PHP, the best bet would be to use a commercial product such as Zend Guard (http://www.zend.com/en/products/guard/). Any home-brew encryption is not secure in the slightest - your code can be easily reverse-engineered with fairly trivial effort. The page you link to does not have any credibility, it is just someone's side project. They have no accountability or stake in protecting your information.
Even these commercial products (Zend Guard, ionCube, phpShield, SourceGuardian) can be decrypted if someone really, really wanted to. No tool or technique in any language can make absolutely secure obfuscation, there is no "unhackable" system. Everything boils down to effort over time.
If it isn't important enough to bother doing it right, then you're probably wasting your time on the issue. Further, if it is absolutely vital that some information or code remain private, you should simply not put it out into the public purview.
[edited for clarity]
Ultimately, you need to trust the encrypting party. If you don't trust them (apparently you don't), then don't give them access to your server (through executing their decryption code/your obfuscated code, possibly with who-knows-what else inside). Simple as that, albeit possibly inconvenient.
php is usually running on the server where the users have no access to the code(neither source nor any other representation) anyways. No reason to obfuscate it there.
Obfuscating php is only useful in the rare cases where you give the php code to clients. For example if you want clients to be able to run their own server but not give them full access to the code.
So, it looks like all it does is obfuscate the code so it's not human-readable. The only way this would really be useful is to prevent lazy people who have access to the code from reading it. However, it uses simple functions to encode/decode, so it would be trivially easy for someone to decode it if they have access.
Which brings me to my point... PHP security works by not allowing anyone to have access to the source file. If someone who shouldn't have access gets it, then this "encoding" thing isn't going to do you any good.
The OP mentioned an interest in protecting database connection details, and it should be kept in mind that no matter what protection system is used for the code itself, the PHP engine and component libraries being opensource sets some absolute limits on what can be achieved. If MySQL connection details, for example, are hidden in a script then these details could be trivially revealed without going near the PHP scripts themselves simply by running the scripts with a PHP build that had slight modifications to the MySQL library or the associated PHP module wrapper. Even hiding the details in a C module as suggested by Chris L. would afford no extra protection in this case. Good protection can certainly be given to source code with compiled code systems such as ionCube and Zend, but wherever data hits routines in the PHP core then it can be exposed.
Obviously for any online service where you may be sending sensitive details, you should use due diligence and make best efforts to ensure that it has a good pedigree. Apart from anything else, not having a working https URL for the site the OP questioned should immediately warn that it's a no-no, and not just for the lack of connection encryption but showing that they are not offering a service that they consider to be serious.
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.
I am selling PHP script online at 35$ for a individual user
Is there any way to identify whether , my script is hosted by more than one user ..
Should i use any logic in my script to find his identity?
Is there an easy way to find the pirator
Please help me.
(sorry for grammatical mistakes)
For example, somewhere in your script:
<?php
file_get_contents('http://yourserver.com/tranck_script_users.php?site='.url_encode($_SERVER['HTTP_HOST']));
?>
This way you will see which hosts use your script. Of course, anyone can remove this line from your script, there is no 100% way to know for sure.
If you can, try to make simple calls to a server of yours to track the script usage, you should send the domain name and the IP. Use cURL for this. If your business logic permits this you can go as far as disabling the script functionality if tracking is not successful.
Because PHP is just plain text anyone can remove your tracking code portion. Try to obfuscate the code.
There is no reliable way in PHP to prevent someone else using your script. Because PHP uses just-in-time compilation, the source code can be read by anyone with access to the files. This means that any call-home logic you put into your script can easily be disabled. The best you can do is obfuscate it, but the code can still be edited by anyone with sufficient determination.
Your best solution is to use a good licence, or to develop in a language that can be distributed already compiled. With PHP, there is not a reliable way to prevent re-use of your source code.
I would urge you not to put any kind of call-home functionality into your script. First, it can be disabled, so is essentially useless. Second, it will cause significant delays even for legitimate users of your script. Finally, if you must put it in, it is vital that you tell your users that you are doing so.
There isn't much you can do to negate piracy with non-compiled scripts. Anybody can modify the source to remove whatever protections you have in place. You can, however, try to run the script through some sort of obfuscation tool, or otherwise try to manually "encode" the file, in much the same way a lot of PHP malware does. Obfuscation and this type of encoding can and will be beaten by somebody with enough time on their hands, though.
If you're willing to invest some money into the problem, you could check out IonCube Encoder or Zend Guard. Both of which will secure your script, and I know at least Zend Guard allows for per-server licensing. These solutions would require your end-users to have either the IonCube or Zend loaders installed, though.
There is no way to do this without (IMO) impacting the security/privacy of your users.
The only "clean" way to do this is to encode your scripts with a tool like IonCube (there are many others but never used them) and restrict the execution on a specific domain. The downside (you can also see this as a plus depending of your license scheme) is that the users can't see/modify your code.
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)
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.