Ilia Alshanetsky wrote: > > On 11-Jan-07, at 9:41 AM, Alain Williams wrote: > >> This has just appeared: >> >> http://www.theregister.co.uk/2007/01/11/php_apps_security/ > > Of many people who use PHP not many have strong programming background > and even fewer experience with security. The use PHP because it makes it > easy to solve problems, especially in a web environment. When you > consider this it is hardly surprising that many people write bad and/or > insecure code. While PHP does try to make things better, and > occasionally has bugs in the language core you need to realize that PHP > is a programming language. As such if you really want to shoot yourself > in the foot you can, just as you can do with C/C++/Perl/Python/etc...
This is exactly what the article said. "PHP shouldn't be blamed for its popularity, so I don't want readers to get the wrong idea. Many lower level languages like C/C++ are even more popular and give developers far more rope to hang themselves than PHP. Therefore, there are other issues at play. "Applications written in every language can, will, and have had a myriad of security vulnerabilities over the years. It doesn't matter if it's C++, Perl, ASP, Visual Basic, Python, or Ruby and Ruby on Rails. [...] "I have no doubt that some PHP Group developers shake their head at the very basic security mistakes that many new programmers make. The problems are all over the web. They're user issues, so they probably don't concern themselves with them. But they should. [...] "I'm not saying the PHP Group is responsible, but they could help. As architects of the language they should consider ways of hardening the language and its defaults against some of the real basic mistakes so many people are making." The developers of the major PHP applications have to take some responsibility as well. A sysadmin once told me "I'd disable register_globals but the users complain that their applications break". No doubt it's a common story. Mark Krenz makes the same argument about safe mode. It can be difficult to make things work in safe mode, open_basedir is much easier and probably more secure. Magic quotes are a nuisance for programmers at any level, definitely a misfeature. The best way to avoid SQL injection is to use a query builder, like we do in MediaWiki. PHP should have one built in. Prepared statements, as in PDO, are a useful step in the right direction. Shell escaping could be handled in a similar way. PHP does not even have a working cross-platform shell escaping function. I would like to see spawnlp-style functions in PHP -- you can't have shell injection when you don't use the shell. The situation with HTML injection (XSS) is much the same. The historic lack of HTML construction functions means that programmers put the strings together themselves, often not bothering to escape user input. An HTML construction library which makes a clear distinction between HTML and text input would go some way towards solving this, if it was promoted well enough. Maybe DOM does this already, I'll tell you once I manage to comprehend the documentation. It's certainly more verbose than the equivalent in Perl. Over and over, we see security vulnerabilities introduced due to the manipulation of text-like protocols using string concatenation and interpolation. The solution is to handle each and every one as a protocol, not as a string. -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
