Drupal Warns Users of Mass, Automated Attacks On Critical Flaw
Trailrunner7 writes The maintainers of the Drupal content management system are warning users that any site owners who haven't patched a critical vulnerability in Drupal Core disclosed earlier this month should consider their sites to be compromised. The vulnerability, which became public on Oct. 15, is a SQL injection flaw in a Drupal module that's designed specifically to help prevent SQL injection attacks. Shortly after the disclosure of the vulnerability, attackers began exploiting it using automated attacks. One of the factors that makes this vulnerability so problematic is that it allows an attacker to compromise a target site without needing an account and there may be no trace of the attack afterward.
How do prepared statements handle the not uncommon situation where you want to include an "in" clause? For example:
select * from customers where city in ?citylist
This was the problem they tried to solve by dynamically creating a statement like:
select * from customers where city in (?city-1, ?city-2, ?city-3)
So, to generate the -1, -2, and -3 parts they relied upon the index of the array.
Only in PHP an array will turn around and bite you with it's dual personality as a hash table. A hash table where one key was not "-1" but rathersomething like (pseudo):
-1); drop table students; --
You cannot really fault the Drupal developers for trying to support this commonly occurring pattern, for which there are no good solutions with plain prepared statements. After all, if they could write secure code for a common problem that could prevent less experienced developers for falling back to error-prone and insecure string interpolation.
Don't get me wrong: The drupal developers is at fault. But they were set up by the criminally insecure PHP.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*