[Twisted-Python] unicode for pyPgSQL
glyph at twistedmatrix.com
Wed Aug 12 13:13:57 EDT 2009
On Wed, Aug 12, 2009 at 12:51 PM, <exarkun at twistedmatrix.com> wrote:
> I did recently learn that pyPgSQL doesn't support bind parameters,
> apparently resulting in almost any use of it insecure and vulnerable to
> SQL injection attacks. You may want to investigate this further before
> deciding if it's worth figuring out how unicode works.
I believe exarkun is referring to this article:
I had a private discussion with the author to clarify. In order to avoid
spreading FUD, I'd like to draw your attention to this note he added to the
bottom of the post as a result of that discussion:
P.P.S.: To clarify, I haven't demonstrated an SQL injection vulnerability in
pyPGSQL. It's not about the performance penalty either. It's about escaping
done by the client library (the basic implementation of bind parameters
without using the database's support) being a second-rate security solution
to explicitly telling the database "here is the code. Now here's the data"
(prepared statements). It's about decreasing code complexity and reducing
chances for "misunderstandings" (and configuration, e.g., encoding,
discrepancies). It's about assurance and choosing safer technologies and
So, to be clear, I don't believe there are any *demonstrated* injection
vulnerabilities (although if someone has a reference to a current one, that
would be helpful); it's just that pyPgSQL goes with an unnecessarily risky
and poorly-performing implementation strategy for quoting parameters. This
dates back to Postgres itself having poor client-library support for bind
parameters in versions previous to 7; unfortunately this means that most of
the other database bindings for postgres use a similarly bad strategy (and
as Mr. Meunier mentions in his post, the ones which do support bind
parameters have other issues).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python