On Wed, Dec 17, 2008 at 11:32 AM, Travis Veazey <travis.vea...@uberforge.com> wrote: > if you have a database you risk > being exposed to SQL injection attacks if you do not harden your app against > them.
This is actually two statements: 1. If you have a SQL database, you run some theoretical risk of SQL injection attacks (exactly how much of a risk depends on your own code). 2. If you have a SQL database, you must individually ensure that every application is hardened against SQL injection attacks. The first statement is true. The second statement is only trivially true, because we're talking about programming here. In some languages the common practice is to write and rewrite database-access code from scratch with each new application, requiring the developer to also write and rewrite code to protect against SQL injection with each new application. In other languages -- and Python is one of these languages -- the common practice is instead to either make use of an existing library for database access, or to have a standard, agreed-upon API which will be implemented by all database-access libraries, meaning that the necessary code to harden against SQL injection must only be implemented, at most, *once per database-access library*. In Python there is such a standard, agreed-upon API, and that API is specified by PEP 249[1]. The standard API includes all of the necessary mechanics to prevent injection attacks, by allowing and *encouraging* paramaterized queries, such that the querying API takes the query string and the query parameters as two separate arguments, and will combine them in a known-safe manner to execute the query. As a result, any code which uses a library database-access library implementing PEP 249, and which uses the parameterized query style to interact with that library, is quite reasonably safe against SQL injection attempts. It's worth noting that: 1. The common practice in Python programming is to use parameterized queries, 2. Django's access to your database is entirely mediated through libraries which implement PEP 249, and 3. Django uses parameterized queries. As a result, individual Django applications do *not* generally need to worry about SQL injection (I say "generally", however, because of course an application is free to grab a raw database cursor and do whatever it likes, including executing non-paramaterized queries or otherwise constructing queries in an unsafe fashion, but Django's own object-relational mapper does not do this), because the necessary worrying has already been done and the necessary code has already been written and is already being used automatically. [1] http://www.python.org/dev/peps/pep-0249/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
