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).
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.
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 -- Steve Holden +1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/
-- http://mail.python.org/mailman/listinfo/python-list
