And before someone makes a "joke" about PHP, they're using the PDO framework which supports bindParam(). Seems like woful incompetence in the Drupal codebase to me.
Exploit in detail: https://www.sektioneins.de/en/advisories/advisory-012014-dru...
I don't think bindParam will allow you to bind an array into a tuple , the only way to pass the tuple is by forming it as a string and adding that to the query string.
I'm using a Micro ORM (Insight Database, https://github.com/jonwagner/Insight.Database) that takes advantage of this. It maps a parameter of type IEnumerable<SomeType> automatically to a TVP. This ORM works brilliantly when you want to get everything out of SQL.
The problem here was a mistake someone made, not a fundamental support problem with the language.
This is precisely why people mock PHP developers. :/ So many don't even understand how the language f'n works.
It has nothing to do with passing security audits or withstanding attacks, there's not a security flauw in the way PHP handles this because PHP or specifically the PDO framework relies on the user to implement this themself. There obviously can't be a security flaw in something which does not exist.
A quick Google search suggests it is not at all obvious to many how to do a parametrised query with an IN-clause using PDO. The highest ranking answer is this SO post: http://stackoverflow.com/a/1586650
Having to iterate the array yourself adding the right amount of placeholders and binding individual values is secure but a lot of boilerplate. Escaping values in PHP and concatting them in the old fashioned way ought to be safe but everyone switched to parametrised queries for a reason: in practice it's often fucked up which leads to security vulnerabilities. The last one, the find_in_set trick, is a clever kludge but a kludge nonetheless.
People shouldn't need to roll their own way to do this because that's where unnecessary mistakes get made.
Alot of programmers can't do FizzBuzz either. If you can't figure out how to iterate and count an array on your own...
I'm sorry but I have 0 sympathy.
Plus, they might be able to figure out how to iterate and count an array but they might also figure out how to use implode instead which is less code and programmers tend to be lazy. And suddenly they've opened their app up to SQL injection because they forgot or are unaware they now need to do escaping despite using prepared statements.
And since their app might contain my data, I care about this and not just think "those idiots brought it upon themselves".
The only explanation for not doing that is ignorance and/or incompetence. Mistakes happen but to claim its a language problem is incorrect.
http://php.net/manual/en/pdostatement.bindparam.php
<?php /* Execute a prepared statement by binding PHP variables */ $calories = 150; $colour = 'red'; $sth = $dbh->prepare('SELECT name, colour, calories FROM fruit WHERE calories < ? AND colour = ?'); $sth->bindParam(1, $calories, PDO::PARAM_INT); $sth->bindParam(2, $colour, PDO::PARAM_STR, 12); $sth->execute(); ?>
So what you do is you write a function to convert the array to a series of ?'s for the IN clause/tuple and then iterate through the array to bind the parameters.
http://php.net/manual/en/pdo.constants.php
You can write "SELECT calories FROM fruit WHERE name IN (? , ?, ?)" and then bind the parameters as strings but this will only work in cases where the length of the tuple is known and fixed. If you need to allow for a variable length tuple then you will need to concatenate the query string yourself.
Dynamically rewriting the SQL isn't going to be tractable in all cases - doing `IN (NULL)` might be a valid value - and throwing an exception is poor form for an actually valid case.
What part of you needed to write a function was unclear? o.O
Counting an array is a safe operation.
No user input involved.
Of course you can. Everyone here is saying you shouldn't have to. This is the perfect type of thing to move into the db library. That makes it much safer because you don't have to hand-roll the same stupid code in 50,000 places (and possibly fat-finger it once).
Is 'elegance creep' a thing? I would be willing to bet money I don't have, that it's because someone thought it was more elegant and clever, and therefore just better.
The question is whether Drupal really needed to implement their own engine for this, though.
If your database supports it set PDO::ATTR_EMULATE_PREPARES to false. If not, I'd still take PDO's implementation over a million different implementations which other projects come up with such as this one.