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.
Your application calls the following action from some web form where username is passed in by the user.
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:
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.
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.