whoops, forget that, it's not possible as the sql injection would undo the ESCAPE clause
> From: gert_corth...@hotmail.com > To: sqlite-users@sqlite.org > Date: Thu, 20 Oct 2011 14:55:00 +0200 > Subject: Re: [sqlite] string conatenated sql statements > > > > > > > To: sqlite-users@sqlite.org > > From: itandet...@mvps.org > > Date: Thu, 20 Oct 2011 07:55:26 -0400 > > Subject: Re: [sqlite] string conatenated sql statements > > > > Gert Corthout <gert_corth...@hotmail.com> wrote: > > > My argument so far is that parametrized queries are way faster if used > > > properly. > > > The next obvious argument is sql injection. On all string input a simple > > > conversion is done: any ' is replaced by '', that's it. > > > This seems to block off any sql injection right there as the escape > > > character \ doesn't work in sqlite. > > > > Yes, this should be sufficient to prevent the attack. %q specifier in > > sqlite3_mprintf performs the same manipulation, for the same reasons: > > > > http://www.sqlite.org/c3ref/mprintf.html > > > > > Alternatively can I make sql statements fail by including funky > > > characters or character combinations? > > > > It would be difficult to get SQLite to crash outright. It would take any > > sequence of bytes and stuff it into the database as-is. That said, you > > might get strange results with strings that are not well-formed UTF-8 or > > UTF-16 sequences (depending on which API flavor you are using). However, > > this is equally true for strings bound as parameters as well as string > > literals embedded directly into the statement. > > > > Performance is really the strongest argument. sqlite3_prepare is a fairly > > expensive operation, it's beneficial to run it once and reuse the statement > > many times with different parameters. Plus the time you save on not having > > to pre-process the strings, plus the peace of mind knowing that you haven't > > accidentally missed a spot where such pre-processing would be necessary. > > -- > > Thank you for your response, I tought as much. > I can see only 1 very long-shot security issue. Assuming I am a malafide > programmer at our company I could add ESCAPE ']' to a vital query that takes > user input and then use ]' to break out and inject some SQL in the live > system, right? > > kind regards, > Gert > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
