The exciting life of a software developer and nerd

Main menu

Post navigation

Death of SQL Injection, long live SQL Injection

I very rarely hear people talking about SQL injection anymore. Just a few years ago, it was a very common problem that all developers needed to understand, in and out. My guess is, the prevalence of database abstraction layers in all languages have helped remove this problem from most developers minds. Hibernate, ActiveRecord, Zend_DB, and all the other frameworks in nearly every language are used much more than hand-written queries.

The death of SQL injection.

But wait. The principles behind SQL injection are still valid for any and all applications. Yet, I worry many developers don’t understand them, since the grandfather, SQL injection isn’t as prevalent.

SQL injection exploits a core problem, components don’t sanitize their inputs. Components that use this data to communicate with some resource, like a SQL database, are more prone to bad inputs causing serious problems. But databases aren’t the only concern. REST API’s, file systems, and many more resources can have the same security vulnerabilities.

Imagine a REST API, with the following URL structure.

http://rest_service/<username>/<action>

Your application calls the following action from some web form where username is passed in by the user.

http://rest_service/<username>/get

If the username portion of the URL isn’t sanitized before getting passed to the API, your application now allows REST injection.

Some smart hacker then enters in the username:

brian.hartsock/delete?

Now, your application is going to call the following URL, effectively ursurping what your application is intending to do, just get data, and instead delete data.

http://rest_service/brian.hartsock/delete?/modify

The silver lining is REST isn’t standardized, unlike SQL, so it is much harder to reverse engineer a site and figure out what to inject. The premise is still important though, components should sanitize their inputs, especially before sending them to resources like databases, file systems, and APIs.

UPDATE – Even though REST isn’t standardized, this doesn’t mean it isn’t a security hole. Jay had a good point, and I have struck that line from the record.

2 thoughts on “Death of SQL Injection, long live SQL Injection”

Something being “non-standard” shouldn’t be a security benefit. No matter what the interface — whether it’s easy to discern attack vectors or not — user data should always be sanitized against attack.

Most companies need only worry about “script kiddie” type of attacks, but as a company gets larger, and becomes a more attractive target, there will be people who specifically target that company — at which point even non-predicatable parts of your system may open themselves up wide for attack by a patient cracker.