On Sat, Mar 26, 2016 at 2:30 PM, Thomas 'PointedEars' Lahn
<pointede...@web.de> wrote:
> Since nothing indicates the used module and accessed DBMS (only that, if it
> is Python code, the module cannot be sqlite3 as that does not support “%s”),
> then this code can, if the module uses an escaping mechanism, still be
> vulnerable to SQL injection. For example, I could input something to the
> effect of
>
> #---------------------------------------------------------------------------
> data = r'\"); DROP TABLE some_table; --'
> #---------------------------------------------------------------------------
>
> if, for example, the string escaping mechanism in the module would simply
> duplicate any double-quote it finds to escape it in the string literal that
> it created (as is possible in MySQL and PostgreSQL), and still inject my
> code because the resulting query would be
>
> insert into some_table (some_column) values ("\"");
> DROP TABLE some_table;
> --")
>
> which is at least syntactically valid MySQL code, but from the perspective
> of the so-attacked it is still not fine as the table would be gone
> afterwards.
In other words, you are assuming that the string escaping *in the
module* is buggy. Well, duh. This is exactly what I said about not
having stupid bugs. The developer of a MySQL binding library should
know the *entire* rules for escaping, and, duh, that's going to
include escaping the backslash. So the escaped query would be
something like:
insert into some_table (some_column) values ("\\"");
DROP TABLE some_table;
--")
which would be interpreted correctly by MySQL.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
