> 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
