Demonstrating Sql Injection Attacks To My Boss

So I have a project with work to try and teach my boss to start using prepared SQL statements, but he could care less and says it's not a big deal. I want to know how to prove to h

Solution 1:

You can't issue multi-query SQL in PHP's ext/mysql interface. So you can't do the ; DROP TABLE Students trick at all. This one of the few points in favor of the deprecated mysql extension.

Ironically, PDO supports multi-query by default for all queries. And Mysqli supports it only if you explicitly call mysqli::multi_query().

But DROP TABLE is not the only illicit thing an attacker may try to do with SQL injection. In fact, an attack that does DROP TABLE is malicious, but gains the attacker nothing of value. Most SQL injection attacks are more methodical.

I can think of an exploit for your example INSERT statement:

http://yourapp.example.com/cable_types.php?supervisor=jflay',(SELECT GROUP_CONCAT(CONCAT(table_name,'.',column_name)) FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema=DATABASE()), NULL, NULL) --

Voilà! I have just created a cable type whose comment tells me all the tables and columns in your database. I can then use this knowledge in subsequent attempts to exploit other pages in your site.

(Actually, this may not be a sure example, because GROUP_CONCAT has a length limit of 1024 characters by default, and your full set of columns is probably longer than that. You can use this exploit to get the same information but perhaps it'll take several INSERT queries.)

Anyway, your boss really should use parameterized queries for the sake of security, and also for the sake of supporting strings containing apostrophes, but also ease of coding and for performance. Tell him that prepared statements perform 14% faster than non-prepared statements.

Solution 2:

Send him the old story of Exploits of a Mom:

There's a nice example of numerous MySQL injection attacks here: http://www.rackspace.com/knowledge_center/article/sql-injection-in-mysql

(Modern?) PHP prevents multiple statements being issued qith mysql_query, which helps stop some types of SQL injection: https://stackoverflow.com/a/10663100/74585

The old book CGI Programming with Perl, 2nd Edition is worth a read, even if you don't use CGI or perl, as its security chapter brilliantly demonstrates that the essence of avoiding things like SQL injection attacks is to never trust input from the user.

Solution 3:

If you store your customers in a database, try using Tom O'Brian as a customer name, and watch the insert statement fail. Then explain that he's losing business because of it.