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?)
_______________________________________________ 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
