Steve Holden <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> John Bokma wrote:
> > Alan Little wrote:
> >
> >
> >>Steve Holden <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Your statement then becomes
> >>>
> >>>select * from foo where bar=1; drop table foo
> >>>
> >>>which is clearly not such a good idea.
> >>
> >>I'm sure Steve is very well aware of this and was just providing a
> >>simple and obvious example, nevertheless it might be worth pointing
> >>out that anyody who connects their web application to their database
> >>as a user that has DROP TABLE privileges, would clearly be in need of
> >>a lot more help on basic security concepts than just advice on
> >>choosing a programming language.
> >
> >
> > True. But how does it stop someone who uses inserts? (I exclude the case
> > inserts are not needed).
Inserts are indeed not needed, if you really don't want to allow them.
The web app user connects to a schema that has no direct write
privileges on anything. Instead it has execute permissions on stored
procedures in another schema that do the writes. In Oracle, at any
rate, the stored procedure then runs with the privileges of the schema
it is in, but the calling user doesn't need or get those privileges.
Over the top in many cases, but it's an extra layer of defence if you
want it.
> >
> >
> >>This goes back to the point somebody made earlier on in the thread -
> >>many web applications can be implemented as fairly simple wrappers
> >>around properly designed databases. "Properly designed" includes
> >>giving some thought to table ownership and privileges.
> >
> >
> > One should stop SQL injection always, no matter if the database takes care
> > of it or not. There is no excuse (like, yeah, but I set up the privileges
> > right) for allowing SQL injection, ever.
Wasn't suggesting that for a moment.
> >
> Correct. If a thing can't go wrong, it won't.
>
> In security several levels of defense are better than just one, so
> database authorization and SQL injection removal should be considered
> complimentary techniques of a "belt and braces" (US: "belt and
> suspenders") approach.
>
> regards
> Steve
I completely agree of course. Do both.
--
http://mail.python.org/mailman/listinfo/python-list
