Govinda <> wrote:

>>> Ah, but what if I use sqlite or postgres?
>> Or Firebird ;)
>good point.
>>> IMHO, the discussion needs to be a the best way to prevent SQL
>injection across
>>> all possible DB types.  Not just mysql.
>> The main thing to avoid is building queries from elements that are
>directly loaded from the form inputs. While it is difficult to build
>sort elements for queries that use parameters, having a mechanism like
>ADOdb's datadict where one can filter SQL based on the identified field
>names does make life easier.
>> While the problems of dealing with student names such as 'Delete from
>student' are easily solved by only using them in parameter arrays.
>> A few simple basics cover the vast majority of traditional SQL
>injection problems?
>Yes, apparently.
>Part of why I even asked is to get a sense of the shelf life on legacy
>code (that relies on escaping) which I am not keen to have to re-write,
>for free, until I really must.
>PHP General Mailing List (
>To unsubscribe, visit:

I think you can happily sanitise data where it makes sense, and use bound 
parameters elsewise. So when you expect a number, its easy to check for and 
force a sensible default. Likewise for things like dates, or names of articles 
(probably a popular need with a CMS) you can check and enforce particular 

Outside of that, without bound params you run a potential risk (even if only 
slight). You can do stuff like base64 encode values, but then you lose a lot of 
the ability to search through your DB after.


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to