...as for Stephen, Mr Beal you need to get out more LOL! Little Johnny Tables indeed. Rub it in, why not? LOL
On 12 August 2016 at 09:38, Michael Falconer <michael.j.falco...@gmail.com> wrote: > Thanks all, > > must admit to being around db's for years but I never did get my head > around the whole injection thing, sad but true. Keith summed it up in usual > succinct fashion which when read by one old hack cause much reddening of > the facial features. Bugger, says I, that speaks my language and it's > saying you are a goose! I'm admitting to no more! > > Thanks all for opening my eyes, at long last, and excuse me while I grep > my code for sqlite3_exec()....grr...damn....etc. > > > On 11 August 2016 at 23:40, Quan Yong Zhai <q...@msn.com> wrote: > >> > From: michael.j.falco...@gmail.com >> > Date: Thu, 11 Aug 2016 15:53:39 +1000 >> > To: sqlite-users@mailinglists.sqlite.org >> > Subject: Re: [sqlite] Exec vs Prepare, step, finalize. >> > >> > 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. >> sqlite3_mprintf http://www.sqlite.org/c3ref/mprintf.html provide some >> formattingoptions to defending SQL injection. '%Q' to quote string >> parameters, '%w' to quote table name or column name.. >> >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 >> > >> > 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. >> > >> >> I am not a security expert, but I think the culprit of SQL injection >> vulnerability in SQLite is not sqlite3_exec(). It's the way how the SQL >> command text constructed. if you look into the SQLite source code, there >> are many places used sqlite3_exec(), and theparameters are carefully >> quoted by '%Q', '%q' or '%w'. >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > > > > -- > Regards, > Michael.j.Falconer. > -- Regards, Michael.j.Falconer. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
