On 4/17/19, Peter da Silva <res...@gmail.com> wrote: > whether it's a > bound parameter or a constant in the query string doesn't tell you if it's > from a trusted source or not.
How do you get an SQL injection vulnerability to call sqlite3_bind()? Worse case is that the attacker can make use of an existing parameter value that was already available in the application. So, for example, if the application were written in TCL, then the attacker could inject a parameter that is the name of any global TCL variable and cause the value of that TCL variable to be bound. But probably the attacker could not control the value of that TCL variable - he has to make due with what is already there. So if an application-defined SQL function requires that one or more of its input parameters be from a parameter, that restricts what an attacker can do with that function using an SQL injection. It does not completely prevent mischief, but it makes it more difficult. Without the sqlite3_value_frombind() restriction, an attacker that can do SQL injection can trivially inject whatever value he desires into the function parameter. With the sqlite3_value_fromblob() restriction, the attackers choices are quite a much more restricted, and may be an empty set, depending on the system. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
