Twist Two [SQL Injection]

Twist #2 — The time saved by not using parameterized queries to build SQL statements should be used to read about using parameterized queries.

Nothing much to add here that I haven’t already exhausted. Instead, revisit some web hacking history with one of the first SQL injection attacks from 1999, created by Rain Forest Puppy. The following snippet of code sums up the attack nicely, default files, no validation, shell execution:

$query="select * from MSysModules where name='|shell(\"$command\")|'";

There were several lessons to be learned from this hack:

  • Remove example content (e.g. databases — if you can call an MS Access file a database…) from systems. Note the omission of “production” in front of systems. Why do you need example content on QA systems? Most of the time you don’t even need it on dev systems.
  • Prohibit direct access to a datastore. (This goes double for the NoSQL crews for whom security relies “run it on an isolated, trusted network.”) You’d think this is stating the obvious, but reality proves otherwise…
  • Remove or require strong authentication for administration capabilities. The newdsn.exe file was open to all. There have been hundreds of similar examples since then.

Even if SQL injection finally dies, it’s likely to be replaced by JavaScript injection against NoSQL data stores. Instead of OR 1=1 we’ll start creating lists of payloads like (while(1){}). There’s a big difference between throwing an access control mechanism on top of a datastore and applying security principles to the queries going into that datastore.

Published by Mike Shema

Security, RPGs, and writing. Immersed in music (80s), sci-fi (dystopian), and horror (spooky). #synthwave Host of the Application Security Weekly podcast.