Doesn't it depend on where and why you intend to execute the code? Obviously some SQL is more at risk for exploit when the input is from the screen on a web page than if you were running parameterized code in a controlled batch environment. Or if you were writing code generators (which is what I happen to do) which won't be run by the general public.
Incidentally, couldn't input field edits prevent such exploits prior to interpolation? On Fri, Sep 26, 2008 at 11:38 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote: > On Fri, 26 Sep 2008 11:00:59 -0500 > "Michael Mabin" <[EMAIL PROTECTED]> wrote: > > So we can drop a table in an in clause? How is this a use case. > Cartoons > > are funny but actual proof that this example using an in-clause provides > an > > exploit would be more helpful I think. > > I'm not sure what proof you require. If you program such that users > can enter arbitrary stings into your database it is obvious that the > exploit in that cartoon can be used against you. And the point is that > it has nothing to do with IN clauses. It can be any SQL. Go read that > cartoon carefully. It says nothing about IN clauses. Consider; > > "UPDATE student SET name = '%s' WHERE student_id = %s" % (name, id); > > Now set name to "Robert'; DROP TABLE student;" and see what happens if > you feed that to your SQL database. Hell, just put "';" in the string > for fun. > > -- > D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves > http://www.druid.net/darcy/ | and a sheep voting on > +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. > -- | _ | * | _ | | _ | _ | * | | * | * | * |
-- http://mail.python.org/mailman/listinfo/python-list
