Re: SQL injection - Mailing list pgsql-general

From Benjamin Smith
Subject Re: SQL injection
Date
Msg-id 200511040041.19027.lists@benjamindsmith.com
Whole thread Raw
In response to Re: SQL injection  (Kevin Murphy <murphy@genome.chop.edu>)
List pgsql-general
Prepared statements are the way to go.

I developed my own prepared statements methodology (I called it "SafeQuery")
some time back before discovering that others had done it. It's so nice,
since I've not worried about SQL injection for YEARS.

Sample of my API:

<?
$sql="SELECT auth.login
 FROM auth
 WHERE username='[username]'
 AND password='[password]'
 ";
$todb=array('username'=>$_REQUEST['username'],
 'password'=>$_REQUEST['password']);
if (!$res=$MDB->SafeQuery($sql, $todb))
 return Error("Database query failure");
?>

SafeQuery checks:
    1) That the variables in the query (in brackets) and in the input array all
match up.
    2) Runs pg_escape_string on all elements in $todb;
    3) Copy/Pastes strings from the array into the query.
    4) Runs query against DB, returns results from pg_exec();

-Ben

On Tuesday 01 November 2005 05:27, Kevin Murphy wrote:
> Can some knowledgeable person set the record straight on SQL injection,
> please?  I thought that the simple answer was to use prepared statements
> with bind variables (except when you are letting the user specify whole
> chunks of SQL, ugh), but there are many people posting who either don't
> know about prepared statements or know something I don't.
>
> Thanks,
> Kevin Murphy
>
> P.S.  I don't use PHP, but google informs me that PHP definitely has
> prepared statement options: PEAR::DB, PDO in 5.X+, etc.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Image File System Question
Next
From: "Peter Filipov"
Date:
Subject: records to text representation