Actually it's not vulnerable because the strings are escaped first. My point
is simply that using prepared statements would have been more robust than
escaping strings on the client side. I'm sorry I didn't make that clear, I'll
go edit my post now.
Thanks!
Pascal
Kenneth Van Wyk wrote:
> Here's one for the daily UGH!
>
> Great points raised by Pascal Meunier (see below) about poorly
> implemented language support for Prepared Statement SQL calls. In
> particular, Python's pyPGSQL actually takes its prepared statement and
> translates internally to an old-style concatenated string query, thereby
> opening itself up to various SQL injection vulnerabilities.
>
> http://www.cerias.purdue.edu/site/blog/post/beware_sql_injections_due_to_missing_prepared_statement_support/#When:16:32:23Z
>
>
> Interesting article, Pascal. Thanks!
>
> Cheers,
>
> Ken
>
> -
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
>
> (This email is digitally signed with a free x.509 certificate from
> CAcert. If you're unable to verify the signature, try getting their root
> CA certificate at http://www.cacert.org -- for free.)
>
>
>
>
> ___
> Secure Coding mailing list (SC-L) SC-L@securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> ___
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___