Govinda <govinda.webdnat...@gmail.com> 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. > > >-Govinda >-- >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 characters. 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. Thanks, Ash http://ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
