X-Original-To: pgsql-www-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 933139FA279 for ; Tue, 23 May 2006 14:33:28 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 05109-09 for ; Tue, 23 May 2006 14:33:17 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mx-2.sollentuna.net (mx-2.sollentuna.net [195.84.163.199]) by postgresql.org (Postfix) with ESMTP id B206C9FA169 for ; Tue, 23 May 2006 14:33:17 -0300 (ADT) Received: from ALGOL.sollentuna.se (janus.sollentuna.se [62.65.68.67]) by mx-2.sollentuna.net (Postfix) with ESMTP id 9B1B28F289; Tue, 23 May 2006 19:33:16 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Re: Your FAQ page :-) Date: Tue, 23 May 2006 19:33:15 +0200 Message-ID: <6BCB9D8A16AC4241919521715F4D8BCEA0F9AE@algol.sollentuna.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your FAQ page :-) Thread-Index: AcZ+jq7QKRjIcgjBQ4e/T+M3JnE+tgAACwZg From: "Magnus Hagander" To: "Josh Berkus" Cc: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/147 X-Sequence-Number: 10110 > > Applications which use parameterized prepared statement syntax=20 > > exclusively (e.g. "SELECT * FROM table WHERE id =3D ?", $var1). > > > > > > Umm. AFAIK that's only true if the client library actually uses=20 > > paremetrised queries over the wire, which I'm quite sure=20 > all don't. I=20 > > beleive PHP doesn't, at leas tnot until the very latest=20 > version, for=20 > > example. >=20 > Hmmm. Can you think of a way to re-word that without doing=20 > an entire paragraph? The wording I have for the bugtraq post (out in a couple of minutes) is: * If application always sends untrusted strings as out-of-line parameters, instead of embedding them into SQL commands, it is not vulnerable. This is only available in PostgreSQL 7.4 or later. Based on Toms suggestion. Though that may be a bit too technical? ;) //Magnus