Kenneth Downs wrote:
In SQL Injection, the user accesses some table they are not supposed to access. This can only be done if the application connects to the database as some generic user, where that generic user can do anything it wants.
Not always. Sometimes it's about accessing a row they're not supposed to access, or adding a WHERE clause they're not supposed to run, or a fucntion they're not supposed to be able to call. Table level security is not enough. For example, you may well have data from multiple users ion one table (you usually will in fact) but don't want Bob to be able to see Alice's data. If Bob can change "WHERE user = 'Bob'" to "WHERE user = 'Bob' or user = 'Alice'" your table level security has just been broken. :-(
There are also attacks that access columns the user isn't supposed to see. A credit card company may allow users to see their purchase history, for example, but not see the mercant ID numbers associated with each purchase.
Your scenario assumes users can see entire tables, and more often than not for random web surfers, that is not the security model we want.
-- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
