On Thu, Apr 7, 2016 at 4:42 AM, Thomas 'PointedEars' Lahn
<pointede...@web.de> wrote:
> Chris Angelico wrote:
>
>> 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.
>
> There is no way a version of a module can safely use an escaping mechanism
> that handles all possible *future* cases. Further, there are escaping costs
> on the client to be considered for *every* query.
The cost of escaping is to be considered against the costs of other
options. It's not a question of correctness.
I don't know what future cases you're talking about. If a future
version of the MySQL server alters the parsing rules of strings, it's
not just this escaping that'll be broken - it's *every string
literal*. That would be a major backward compatibility break, and
people would cope appropriately. You're still somehow assuming that
escaping implies that your library is fundamentally buggy.
> So my recommendation, based on best current practice (OWASP), stands: Use
> prepared statements or stored procedures and let the database do the job.
> *Better be safe than sorry.* See xkcd.
Or use parameterized queries and let the database protocol do the job.
Of course, that DOES require that you not use MySQL. Like you say,
better safe than sorry.
> Bonuses with prepared statements: Not only can the client skip the escaping,
> but queries are faster if you have to do the same query just with different
> parameters. And you can do things with prepared statements that you cannot
> do in another way (for example, parameterized LIMIT [1]).
How does a generic client know which statements to save?
Also, what is the issue with parameterized LIMIT? Your footnote is of
no value to large numbers of python-list readers.
> Bonus with stored procedures: You can do more complex tasks with less
> overhead.
And one of the bonuses of floating point numbers over integers is that
you can store fractional values. They're solving different problems.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
