NYCPHP Meetup

[Elliotte Harold]

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  elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/