On Thu, Aug 11, 2016 at 7:53 AM, Michael Falconer < michael.j.falco...@gmail.com> wrote:
> Thanks Jay, > > excellent response. I'll ask for clarity on one statement though. > > That’s the basic theory, but even knowing that, most people get it wrong. > > In short, if you’re using string manipulation functions to build your > query > > string, you’re very very very very likely doing it wrong. > > > > I have a self styled routine (similar to the glibc manual example) for > concatenating the strings values that make up the sql statement. It uses > memcpy rather than the built in strcat etc. So what exactly is the issue > with the string building if it does not include sql derived from user > input? I'm not quite seeing that bit, sorry or the vagueness. > This short strip explains SQL injection better than any book, IMO: https://xkcd.com/327/ It does however sound like it would just be better to adopt the three step > functions as the preferred method in all cases, which is probably what I'm > trying to come to grips with. I do see the prepare/step/finalize process > with bound parameters etc is very much preferred in most cases, but > wondered if those cases where SQL is application provided were an > exception. I'm leaning towards a no on that now. Thanks for your input and > in advance or any additional insight. > FWIW, internally, exec() is just a proxy for prepare/step/finalize. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
