PostgreSQL 8.1.4 Released to Plug Injection Hole 162
alurkar writes to tell us that PostgreSQL released version 8.1.4 today in order to combat a security flaw allowing a SQL injection attack. From the article: "The vulnerability affects PostgreSQL servers exposed to untrusted input, such as input coming from Web forms, in conjunction with multi-byte encodings like (Shift-JIS (SJIS), 8-bit Unicode Transformation Format (UTF-8), 16-bit Unicode Transformation Format (UTF-16), and BIG5. In particular, Berkus says that applications using 'ad-hoc methods to "escape" strings going into the database, such as regexes, or PHP3's addslashes() and magic_quotes' are particularly unsafe. 'Since these bypass database-specific code for safe handling of strings, many such applications will need to be re-written to become secure.'"
Widespread problems... (Score:3, Informative)
Re:This is why... (Score:5, Informative)
It's much easier to prepare a query handle and then execute it as needed:
$sth = $dbh->prepare("SELECT a,b,c FROM foo WHERE bar=? and baz=?")
$sth->execute($bar, $baz);
Not only is it more efficient (if you're going to use the same query twice), it's secure by default. Let the database programmers handle the Hard Stuff (parsing) so that you can concentrate on your application.
Speaking of which, is there a way to do this in PHP? I've never seen a PHP script that did anything like this (which is probably why bugtraq is 99% php SQL injection holes).
Character encodings yet again (Score:3, Informative)
Mismatches between different character encodings seem to have been responsible for vast swathes of security vulnerabilities over the past few years. The sooner everybody moves to programming languages and software that use Unicode natively, the more secure we will all be.
Unfortunately, the languages receiving the most attention for web development have abysmal Unicode support. PHP and Ruby haven't a clue, although the next version of PHP is supposed to be much better in this respect. Python developers can at least handle things fairly well, although it's still a bit of a pain in the neck.
This vulnerability is probably going to cause quite a few problems for people, as it's a client issue that will probably need whatever adapter you use to be updated. Here is the user guide to the vulnerability for PostgreSQL [postgresql.org]. psycopg should be fixed shortly [initd.org].
Re:This is why... (Score:3, Informative)
PHP5's mysqli extension enables you to use prepared queries.
Someone needs to read the PHP manual... (Score:0, Informative)
Move along, folks. No need to panic.
Use placeholders! (Score:5, Informative)
Re:Character encodings yet again (Score:5, Informative)
Re:This is why... (Score:5, Informative)
Most people probably aren't aware of it, but several years ago, I wrote a few short scripts for PHP 4 [dlitz.net] that specifically address this problem. Currently-supported database backends are MySQL and anything that DBX supports, but it wouldn't take much to adapt it to PostgreSQL.
It basically lets you write code like this:
It doesn't have the performance benefits that real prepared statements have, but I still find it handy for typical PHP4 database work.
The code is released under the MIT license, so feel free to use it.
Re:This is why... (Score:5, Informative)
$db = getConnection();
$sql = 'select * from Foo where id =
$params = array('id' => $id);
$result = $db->query($sql, $params);
Re:I dont see how UTF-8 is vulnerableg (Score:3, Informative)
See http://www.postgresql.org/docs/techdocs.50 [postgresql.org] for the details.
Re:This is why... (Score:3, Informative)
$data = array('one',2);
(short)
$result = $db->query('select * from table where foo=? and bar=?',$data);
(prepare)
$stmt = $db->prepare('select * from table where foo=? and bar=?');
$result = $db->execute($stmt,$data);
Works with mysql, pgsql, mssql... etc etc. MDB2 is the new version of this library which uses much the same syntax. Uses database-specific escaping/quoting automatically.
http://pear.php.net/manual/en/package.database.ph
Re:This is why... (Score:2, Informative)
Re:Widespread problems... (Score:2, Informative)
I recently switched from coding for single company to joining a consulting firm. I'm shocked at how sloppy the commands sent to the database are. It drives me nuts and makes me want to fix all the code... but since I'm low man on the totem pole, my concerns are replied generally with lame excuses like "emulate the coding style of the original author", "we don't get paid much, so it's okay to be sloppy", or "we have a deadline to meet". And no, I can't find a new gig.
Some of the sites I've worked with are vulnerable to this type of injection attack. From my perspective, this is widespread, a bit scary, and should be nice little eye openner as sites get hacked. This may actually be a blessing as I could start pointing what happens with sloppy code and not being given enough time clean everything up.
Re:Widespread problems... (Score:3, Informative)
If a whore is "loads of fun", then she's not worthless, since she can propably get a good price once the word spreads. Just because you are trolling is no excuse to be illogical.
Now let's see if someone mods me Insightfull or Informative...