For those who don't want to do a full core update, you can apply a one line patch by the looks of it.
http://www.reddit.com/r/drupal/comments/2jbuiz/drupal_732_fi...
Drupal 7 SQL Injection Vulnerability
21–30 of 83 posts
Re: Drupal 7 SQL Injection Vulnerability
#22Hmm, my install is not saying there is a core update... Normally it does this.
Re: Drupal 7 SQL Injection Vulnerability
#23The patch is only one line[1], so if you're scared to update Drupal for fear of breaking things you can just patch the vulnerable part.
In this file:
includes/database/database.inc
foreach ($data as $i => $value) {
foreach (array_values($data) as $i => $value) {
Re: Drupal 7 SQL Injection Vulnerability
#24Could this problem be solved by quoting parameters ? I believe PDO has quoting capabilities when it comes to query parameters in prepared statements.i.e. one can state this parameters is a string , or an integer ....
The problem here is that placeholders are added to the query itself to match the amount of array items. These newly constructed placeholders inadvertently contained user data.
Re: Drupal 7 SQL Injection Vulnerability
#25Drupal uses prepared statements in all its SQL queries.
There's this common misconception "just use prepared statements and they'll completely prevent SQL injection" floating around. Good to see (yet another) counterexample of that. Prepared statements and parameters are only strategies that can help, but they don't replace an understanding of where the characters in the query are coming from and how they're being used. Escaping shouldn't be a difficult concept to understand either.
Re: Drupal 7 SQL Injection Vulnerability
#26Could this problem be solved by quoting parameters ? I believe PDO has quoting capabilities when it comes to query parameters in prepared statements.i.e. one can state this parameters is a string , or an integer ....
The problem here is that placeholders are added to the query itself to match the amount of array items. These newly constructed placeholders inadvertently contained user data.
Oh yeah, I see it now,thanks.
They are naming the query placeholders based directly on the indexes passed in the querystring parameters?
And since indexes can be whatever string like ?name[DELETE FROM USERS]=foo&... ,you end up with an exploit ...
Re: Drupal 7 SQL Injection Vulnerability
#27Drupal uses prepared statements in all its SQL queries. There's this common misconception "just use prepared statements and they'll completely prevent SQL injection" floating around. Good to see (yet another) counterexample of that. Prepared statements and parameters are only strategies that can help, but they don't replace an understanding of where the characters in the query are coming from and how they're being us…
These aren't prepared statements. This wouldn't be an issue if they were actual RDBMS prepared statements. These are the bullshit fake prepared statements that PDO emulates by default to achieve cross-database compatibility to offer things like named-parameters (oracle, postgresql support) for databases that only offer positional parameters (mysql, mssql).
It's quite simply shoddy string substitution that's not doing proper escaping, as you pointed out.
Re: Drupal 7 SQL Injection Vulnerability
#28I feel like Hacker News has become home of the "security exploit du jour." There have always been new exploits being found daily, what's changed is the severity and wide reaching nature of said exploits. You might ask, when will we learn? Well, the truth is making secure systems is incredibly hard work and often comes at the price of flexibility/usability/programmer productivity. We know how to do it, it's just not e…
I like hearing about the big ones. I'm subscribed to announcements from the projects I rely on but it's good to have the bigger picture.
Re: Drupal 7 SQL Injection Vulnerability
#29Drupal uses prepared statements in all its SQL queries. There's this common misconception "just use prepared statements and they'll completely prevent SQL injection" floating around. Good to see (yet another) counterexample of that. Prepared statements and parameters are only strategies that can help, but they don't replace an understanding of where the characters in the query are coming from and how they're being us…
If there's one thing I learnt today, I'd make sure my SQL abstraction libraries include test cases which makes sure the libraries barf when presented with bad input.
Re: Drupal 7 SQL Injection Vulnerability
#30PHP proof-of-concept here[1] (one that actually works, the Python one on pastebin.com doesn't.)