Brian Hartsock's Blog

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.

In many startups, the developer of an application is also in charge of managing the server. Since resources are thin, this is how it has to be. Developers don’t always make the best decisions when it comes to managing security concerns on servers though. Here a few tips to you developers in charge of managing servers. Believe me, if you’re successful, you will regret not having followed security best practicies from the beginning.

1. Go Role Based – Having roles helps auditing, plain and simple. If each user is given their own permissions, you have to audit every user and all their permissions. It is much easier to audit roles, and then see which users are in which roles. This can be accomplished with groups in Windows.
2. Don’t share – I have said it before, and I’ll say it again, Sharing is for adolescents. Don’t share logins between multiple people. Each user or application should have different, well-named users. They should instead be sharing roles (see above).
3. Give the least – Remember the time that service wasn’t working for some reason, so you changed it to run as an administrator? Don’t ever do that again. In fact, give everything the least amount of privileges possible. Adding privileges is easy, taking them away is very scary and hard.

Duh right? Well, I bet you have violated all of these at some point. If you follow them when your small, getting big is a lot easier. With size comes auditing and compliance, which shouldn’t be hard but is for all too many organizations. Follow these simple tips, and the day you get audited will be a lot easier.