Interesantes
From Disperso
Lista de comentarios aleatorios que encuentro interesantes.
PHP Security
I've written lots of PHP code [sf.net] in my spare time, and have written an article [kuliukas.com] on creating "rootkits" to covertly inject into PHP scripts (phpBB2 in particular), so I thought I'd chime in. This'll probably be a long post but hopefully it'll give people some things to look out for.
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 scripts 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.
To be honest I'm a big fan of PHP, it's very flexible and lets you develop very quickly and easily; if you have the knowledge and self discipline it's an excellent language. But allowing fast, easy development at the cost of security is insane for a server-side web scripting language! I was hoping that PHP6 was all about doing a 180 degree turn on security, but this article doesn't bode well..
