NYCPHP Meetup

[bz-gmort at beezifies.com]

Kenneth Downs wrote:
> 1) SQL Injection does not let them do anything they can't do anyway, so 
> at most it is a waste of the hacker's time

Many things are a waste of the cracker's time, but they do them anyway. 
  So counting on the result not being worth the time of cracker is 
wishful thinking. :-)

> 2) Our user interface design focuses on the idea that they should see 
> everything they can do, and everything they can see they can do.  Again, 
> SQL Injection only gives them a really crude way to do something that's 
> probably on the menu!

Hmm, I think in terms of online stores and credits.  Sure, the person 
can purchase a credit and have the data in their user record updated, 
but it is so much cheaper to do an "update usertable set credits=10000 
where uid = 'me')

Or someone who doesn't like the clunky deletion interface for the rows 
of a table, and instead wants to do a "delete * from customer_Table"

I suppose one way to work around this is to only give a user access to 
tables they are allowed to have complete control over.  But then 
creating thousands of user tables and then joining them together for 
reporting would be tedious(though you could do the reverse, have 1 user 
table and create an individualized view for each user so the user only 
accesses their data through the view.  Does MySQL 5 allow you to perform 
updates through views?)