Govinda <govinda.webdnat...@gmail.com> wrote:
>>> Ah, but what if I use sqlite or postgres?
>> Or Firebird ;)
>>> IMHO, the discussion needs to be a the best way to prevent SQL
>>> 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
>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 (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php