Let's have the specifics on these PHP holes. http://www.heise-security.co.uk/news/82500 <quote While Esser feels that certain PHP functions are intrinsically unsafe (for example allow_url_fopen/allow_url_include) and should therefore be revised, many developers, including PHP specialists Zend, think that the security problems in PHP applications have simply been caused by inexperienced programmers. </quote
http://developers.slashdot.org/article.pl?sid=06/12/14/0410240 <quote Here are the most common security problems you run into in PHP: * magic_quotes: This adds slashes to all input so that you don't have to sanitize it before it gets inserted into SQL. The problem is that developers write their code with magic_quotes on, but don't realize that it's often turned off elsewhere, which leads to gaping holes. * register_globals: Variables can be placed directly into the global namespace. If you don't explicitly set all variables before using them anything can be injected into them, which brings me on to: * Only critical errors are reported: If you use a variable which isn't set it'll just return null, with no error (unless you specifically turn up the error_reporting level). This means that someone who isn't familiar with the problem won't know that a variable in their _script_ can be written to by anyone until it's being exploited, functions which you would expect to return an error and halt the _script_ if they fail can carry on without giving any indication of failure. * fopen_urls: By default you can include _script_s hosted on other websites! This often makes remote PHP execution, which would otherwise require eval(), much easier. Who would have thought <?php include($var.'/include.php'); ? will run any PHP on any server, anyhere? (The attack in the article above leveraged entry using this, coupled with register_globals.) * Inconsistencies: What one function does can never be applied to what another function does; you can never assume anything with the PHP library and always have to keep a browser window with the PHP manual handy. Using a function without carefully reading up what it does, even when it's very similar to another function you're familiar with, is asking for trouble in PHP. The same goes for just about everything; are you checking whether some input equals some harmless number before passing it on to a SQL query or the browser? Don't forget that (5 == 5 UNION SELECT secret FROM ... ), null == 0 == == false, a == 4 == true; generally you just have to be on your toes. * Input checking is difficult: Do you want htmlentities() or htmlspecialchars() ? Have you remembered to strip_slashes() if magic_quotes is on? Remember the user can input arrays too, are you checking that the input isn't an array? Have you remembered to escape queries with mysql_real_escape_string() ? mysql_escape_string() doesn't account for the character set being used, and so isn't good enough, trying to escape input for yourself is also dangerous. What about null bytes? Remember that the user can input binary data; PHP allows null bytes, and will add a slash to them, but when you send a string with null bytes to some functions, but not others, the null bytes will be silently dropped leaving only slashes. To check input in PHP you have to be absolutely rigorous and take no half measures, people who aren't aware of the dangers don't stand a chance. </quote
http://blog.php-security.org/archives/61-Retired-from-securityphp.net... <quote I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the security of PHP itself you become persona non grata. I stopped counting the times I was called immoral traitor for disclosing security holes in PHP or for developing Suhosin. For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP. </quote - Oliver
Favoured: 0
