Secure Your API Like A Castle

It’s been three years since I compared medieval security to web security, and a few things have happened. Mobile and wireless have evolved as the dominant platforms, while the life between personal computing and business computing has continued to fray. And, of course, thanks to web services, the web-delivered API now dominates the connected world.

It’s time to take a second look, focusing on the API. That is, if our organization is a castle, then the API is the unique services that people can employ, both inside the castle (cooking the food, cleaning the stalls for the horses) and outside, replenishing supplies, or bringing books in and out. While the first and most obvious division that comes to mind is internal or external, we’d like to take a step back and mention threat modeling – through the eyes of a viscount.

It Starts With The Threats To An API… Err, To the Castle.

Medieval Europe was split into counties, each county ruled by a count. There was a special title – viscount – for a county that bordered another nation. While counties were all equal on paper, a viscount’s castle would have a military role, to attack or defend, that others would not. The castles of a viscount would be more likely to look like a fortress, the permanent watch would be higher. Besides proximity to enemy and preventive measures, the value to the enemy, what they could do with the castle, was something to consider. A gold storehouse would probably be more protected from the outside than a prison … but who the prisoners are, and who their friends are, might matter a great deal.

Again, today we’re looking at the services those castles give – so is there really any security threat on the food service inside the castle?

Only if someone might have reason to poison the king.

Back To the 21st Century

We still want to have threat modeling – what do the services allow our customers to do without data and systems? Is there information to steal, a perceived enemy to defeat, or a system to take down? Not all companies are brinks security; few of us are writing software to plan the routes for armored cars. Client lists, and personal identification information such as dates of birth and social security numbers might just worth stealing. The big difference with API’s is that we leave the front gate open, literally inviting other people step up and use the service.

If you don’t have a formalized threat model of your system, building one does not have to be a massive undertaking.

Let’s talk about that front gate.

External APIs typically run over http (port 80) or secure sockets layers, or SSL (on port 443). Most web servers and many tools support port 443 by default. Most of us know the advantage of SSL: The data is encrypted from the client to the end server, preventing snooping “on the wire.” And, unlike middle ages, we can get the computer to do the encrypting and decrypting of the messages as a standard benefit of most web servers.

While most companies look at encryption, not enough consider authentication – how the system recognizes the user. Basic authentication sends the same user/password combination as part of every request, while session management assigns a session id, a unique key, only once when login is required. If an attacker has a valid session id (either by snooping on one machine or having a valid login and looking to abuse the system) they can try a technique called session hijacking, where the attacker attempts random session id’s of similar form to the original – until something works.

Don’t Roll Your Own Security, Use Something Off the Shelf

Twitter, Facebook and Google all have not only public APIs, but also public login systems that trace back to an email address. These systems use oAuth, which can tie your user ID to hardware and send notices when “you” log in from a different machine. Larger organizations also tend to have a security model, often built around a protocol like LDAP.

When it comes to encryption, decryption, and authentication, if you don’t use off-the-shelf components, at least make sure you have a reason why. When it comes time to maintain a legacy API, take another look at the security methods in place.

You might not have funds to rebuild the castle, but adding a pot of boiling oil at the top might help. You can check out Secure Pro here, which is SmartBear’s API security solution.

Consider Internal APIs as If They Were External

Security on internal APIs is easy to ignore. The company should, after all, already be insulated from any attacker. Setting up the security can be a pain and is likely to seem like nobody’s job.

Before standing up that server, give it a second thought. Once security architect I interviewed pointed out that just because an API is designed to not go external does not mean it will never go external.  I can bear witness to that, having developed a web application that allowed external customers to schedule meetings with our employees, extending a Microsoft Outlook API to the outside world.

The second problem with ignoring security on internal APIs is that it missed the idea of defense in depth. My friend the architect put it this way: “I don’t think firewalls can be trusted anymore. They are a good layer of protection, but in security we talk about defense in depth. The castle has a moat but it also has a wall, a portcullis and arrow slits. When you think about it, most internals systems are just a firewall and a network hop away from being exposed to the internet.”

Putting It All Together

APIs provide an alarming number of attack vectors. You could have an external attacker take over a valid system and try to steal information. A valid external user might try to abuse his permissions. An attacker could go under the firewall and attack an internal system, and an internal employee or valid user might try to take off with the data.

Consider a salesperson who is leaving the company but staying in the industry.  Forty years ago, stealing a rolodex was a lot of work. Twenty years ago, he’d have to print out a customer list, which would be visible. Today we are busy writing the API to let him get the data the day before he turns in his resignation. And, sadly, unlike the guards in a real castle, computers and databases are unlikely to mention a strange series of requests to the captain of the guard.

Today we scratched the surface of API security with authorization and transport security. Securing the end-points, and training for social engineering are probably next. Start with threat modeling.

Finally remember, this: An API that can make its way onto the internet, probably will.