[oschwald]

As the article mentions, this issue is not limited to PHP. Many ORMs have similar issues. For instance, I recently ran into essentially the same issue with DBIx::Class in Perl. The problem there was further compounded by the fact that many subroutines in Perl behave differently in different contexts, meaning that code like this may not be safe:

$resulset->search({ column1 => some_sub($arg), column2 => $value2, ...});

Many subs may behave in unexpected ways when using list context, such as returning an empty list. You may end up with values, which are normally escaped, becoming keys in the hashref. DBIC only does the simplest of checks on the key values, leaving your code open to an SQL injection.

This sort of issue is unfortunately prevalent. It is not just limited to PHP and dismissing it as such does everyone a disservice.

[ribasushi]

DBIC maintainer here: did you ever report the problem? Looking through my queues I don't see anything related, but perhaps I missed a report.

I am interested in removing all and any attack vectors, but I can't fix problems without knowing about them. So please do get back to me on this.

Cheers