Slashdot Mirror
Hardened PHP
Frank Kreuzbach writes "Yesterday the Hardened-PHP Project has announced its existence on the PHP-general mailinglist. It is the first public patch for PHP which adds security
hardening features. It is meant as a proactive approach to protect servers against known and unknown weaknesses within PHP scripts or the engine itself. It enforces restrictions on include statements, adds canary protection to allocated memory and other internal structures and protects against internal format string vulnerabilities.
It has syslog support and logs every attack together with the originating ip."
From what I can see this project doesn't do much against protect lazy coders. The features listed are easily protected against by writing non-sloppy code.
I'm not sure that this project is a good thing, as if someone gets used to it and switches to a server without it they might be in trouble.
I don't think the PHP engine is to blame, it's more of an issue with the PHP script developers to make sure they plug all the holes -- sure that's not always possible, however take PHPNuke as an example of poor PHP scripting, SQL injects are possible though a number of the modules. You have to add a high number of 3rd party patches to make the thing secure.
This Hardened PHP is just hand holding the developer into a false sence of security.
It's a way to protect against buffer overflows. You put some known data on the stack, and before returning from each function call, make sure that data hasn't been changed. Most buffer overflow exploits work by overwriting part fo the stack, and canary protection will detect that the stack has been changed, so the exploit code will not run.
My server
I run http://www.uberhacker.com . This site is dedicated to secure PHP programming. It is better to program secure rather than limit coding abilities. Secure programming allows for a wider range of scripts and security.
Actually, I am a PHP developer for some major porn sites. The sites that I work with, however, arent the end user sites that people pay to view, I work with the sites where porn webmasters go to buy their content.
Surprisingly, it has to be fairly dynamic. Most of the work that my software has to do is in posting the content for the first time. You upload a zip, and the software will extract the zip taking the images makes thumbs and full sized samples with embedded watermarks. From this point on, the software is basically an advanced shopping cart with some extra features like the ability to order individual images out of a particular zip, and instant download.
The sites that I have setup are surprisingly popular, and within the past year and a half, the sites I work with have sold closs to half a million dollars worth of porn. That may not seem much to a big business tycoon, but it is when theres only a handfull of people making the profit.
I dont know how well the end user sales are however. I like this hardened php stuff and I think it has great potential. I am waiting for them to come out with a PHP5 version, and then I will jump right on it because all of my newer projects are going to be in php5.
I think it is funny how most /. readers demonstrate how they think from a user perspective, and not from an admin perspective.
Now don't get me wrong, I understand, it's *hard* to think as an admin if you have never *been* one. But when you are an admin on a machine, you don't think "My users will just have to learn how to code secure, then there is no problem."
Sorry folks, just ain't gonna happen!
Joe home who wrote a site just to show off his holliday pictures thinks its swell how easy php is, and he doesn't really care about becoming fluent in php, as long as his little enviroment runs!
Sure, you can try and educate your user, but if you maintain a 500+ user server, security is in YOUR hands. only ONE of your users need make an error, and the whole machine might go down. And the "poor coding is the only reason for security holes" just doesnt cut it there.
Harden your servers, admins. Make the internet a fun place to be.
Mention this on comp.lang.perl.misc and you get flamed for referring to Perl as a web developmnent tool. Well, if the Perl community only sees Perl as a tool for large web projects then so be it but they're making a big mistake. There should be a decent Perl templating engine which can run as an Apache module without exposing the Apache API, so that it would just do the one job well. Until this happens PHP will simply wipe Perl off the map in shared hosting environments.
Hopefully Perl 6//Parrot/Ponie will come up with something to break the inertia as bog-standard Perl CGI is irrelevant these days. Hell, many hosts don't even allow you free reign with installing CPAN modules.
as the japanese car makers discovered (or at least the idea came to prominence) in the 1950s, ANYBODY (even people with 93 PhDs) who assembles something makes mistakes occasionally. the trick is to limit the number of modalities that allow for mistakes. a person who is asked to make a wheel fairing in three minutes using simple hand tools will make far more mistakes than one who has a dedicted stamping machine.
in fact, the japanese cars excelled in quality, worker satisfaction, and in the competitive marketplace for many years in large part that their idea that a) errors are natural stochastic processes b) the rate of errors in an any process is more determined by the design of the process than some inherent quality of the worker and therefore c) when a mistake is made, analyze the process, don't blame the worker as this will lead to d) continuous improvement and also empower workers to speak up.
even the most experienced PhP programmer can make an error. education helps, but fixing the system is a better idea.
Perl was invented to scratch a itch on the commandline, PHP is purely invented for apache and this shows... The problem is not PHP being "slow", the problem is wrongly usage of the database, mostly mysql. Some well known PHP programs use more than 30 queries each go, you can understand that of course a high volume site is out of the question... Further there is also the question with both Perl and PHP, that is a smooth configured Apache that can fork and prefork a number instances from itself to serve connections. Mainly PHP is a C like interperter on steroids... The language is very problem solving by nature and very efficient in that it takes a handfull of statements to solve a complicated matter... I think Perl developers see the same with Perl, my impression is that the same solutions take less code in PHP compared to Perl, but the is my private impression... The largest power of PHP is intuitivity, most constructs you think off work in one or 2 go's while in other Languages often you are buried to death with error messges... And not to forget, instant gratification, you can do more than 1000 runs in a hour when developing...