If you’re accessing and using $_POST['somevar'] without checking and cleaning the value first, then you are asking for trouble. It is perfectly possible to write code without modifying the superglobals themselves – e.g.

You do all further evaluation using your value in $cleanvar – code that pumps superglobal values directly into databases, etc, is what gives rise to all the nasty SQL injection vulnerabilities that come up in popular forum apps all the time.

Have a look at how Perl handles taint checking – it’s a good way to do things.

1. Assigning values to superglobals. If you see something like $_POST['foo'] = ‘bar’ run for your life. It makes absolutely no sense to ADD anything to the list of POST variables (which PHP packages for you in $_POST), therefore the whole program is probably horribly designed.

Many users have already commented on how this technique is sometimes necessary and justified. Also, the latest version of Drupal (4.7 – currently in RC) has a new forms API, meaning that you very seldom need to access $_POST et al directly anymore.

2. ‘Magically’ assigned variables. Savant templates or whatnot, if you are working in a template and have no idea where certain variables are assigned….that’s really not a good thing for extenibility.

Template variables are all clearly defined in one function, using Drupal’s PHPTemplate theme system (other supported theme systems work similarly). I don’t see what’s so magical or mysterious about that.

3. No easy way to configure error handling. Does the software you want to use allow you to determine how errors are logged and where they’re logged to? It’s not that fun trying to track down a bug when the program uses output buffering so nothing is sent to STDOUT but also doesn’t leave a trace in syslog, error_log, …

Drupal does not use output buffering (under most circumstances). It also has a fairly good error handling system, called the ‘watchdog’, which logs all errors to a database table, and allows error messages to be browsed through an admin interface. So I don’t know what you’re getting at here.

All up, I think your criticism of Drupal is unjustified. It has an excellent security record. It uses recommended validation techniques consistently. It is modular and stable. The code is well managed. It scales very well. And a number of large and high-profile sites are using it. It is generally considered a much more developer-friendly app than its competitors in the open-source PHP CMS market, such as Mambo, PHP-Nuke, and Xoops.

I don’t mean to start a flame war, but I think people should hear both sides of the story.

Anyone for creating a simple tutorial on any profiler/debugger? :(

As a side note there, I’d recommend registering on this mailing list—pretty much all security issues with well known (and less well known) PHP Open Source code bases get announced here.

Shame really…

phpsec-subscribe@phparch.com
Delay reason: SMTP error from remote mail server after RCPT TO::
host mail2.tabini.ca [72.51.34.155]: 450 :
Recipient address rejected: User unknown in local recipient table

Relying on sanitizing functions only works if you really know, that every single parameter goes through these functions. And I think PHPXref (or any other automated software) doesn’t give you this possibility. So maybe its not that much worth in application’s evaluating that one may first think.