On Aug 11, 2016, at 12: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. If the values are truly 100% application derived, with no source or root material from any user-generated inputs, config files, etc., then you’re good… assuming you still quote correctly, and so forth. The thing is, that’s rarely the case, and as the program changes and evolves, it is almost inevitable that user-driven values make it into the statements. Yes, that’s a broad, sweeping, generalization, and you know your specific development needs best. But remember that SQL injection attacks are essentially impossible if you correctly use bound parameters, yet it is also considered one of the top 10 security vectors. In 99% of cases, they're really easy to avoid, and yet they’re all over the place. There is a lesson in caution in that. > 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. Be aware that bound parameters are for *values* only. You cannot bind identifiers, which includes database names and table names. From what I gathered in the rest of this discussion, that might be an issue in your case. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
