APIs are widely used in the modern web world to connect users and sites to disparate sources of data, content, and functionality. APIs also represent a window into infrastructure and as such can also be an attack vector ripe for exploitation, unless properly protected.
The topic of API security is one that is often an afterthought, if it’s even considered at all. That’s a situation that Scott Morrison, chief technology officer and chief architect at Layer 7 Technologies is hoping to change. Morrison delivered a presentation at the RSA security conference today titled, “Hacking’s Gilded Age: How APIs Will Increase Risk and Foment IT Chaos,” outlining the risks of APIs as well as providing some suggestions on how to deal with them.
“The great opportunity for hackers is that if they understand the practices of web developers moving into the API world, they will know where to probe,” Morrison told InternetNews.com. “They will know where to look for the common mistakes.”
Among the common mistakes that Morrison sees with APIs is the use of API keys as a means of personal identification.
“An API key is basically an opaque key that is given to a developer of an application,” Morrison explained. “It’s an identifier that is supposed to be able to track a particular application and its use of a given API.”
The security risk occurs when developers confuse application identifiers and personal identifiers — which are supposed to be used for people.
“The collision of those identifiers really shouldn’t happen,” Morrison said.
The risk of having a personal identifier present as part of the API key is that if the API is not secured properly, personally identifiable information could be hacked.
API encryption is another large issue, according to Morrison. If unencrypted API keys are intercepted by an attacker and then re-used, there is no way the receiver can tell if the source is legitimate or not.
“One of the things we’re advocating in the API world is to use SSL everywhere,” Morrison said. “In the web world, we usually only turn on SSL when something of real value is happening, like inputting a credit card number.”
In contrast, APIs in general have parameters that need to be protected, whether it’s a unique identifier or keys that kick off a transaction. In Morisson’s view, the reason why many APIs don’t have ubiquitous SSL protection is simply an artifact of habit: Web developers are not used to do it on the web, and they haven’t understood that APIs are different.
Injection Risk
Another risk with APIs is the potential for SQL Injection, which is among the most dangerous and common type of exploits on the web today.
According to Morisson, APIs in some ways actually make it easier for attackers to attempt SQL injection attacks. APIs are self-documenting, providing information on usage and connections, whereas the web is more obfuscated in terms of the underlying structure of what is going into a database.
“Hackers don’t have to work hard at all in the API world to get a SQL injection, as it’s usually pretty obvious what the database mappings are,” Morrison said. “So it’s much quicker to figure out if an API is in fact vulnerable to a SQL injection.”
In a SQL injection attack, bad data is inserted into a SQL command that can then be leveraged to exploit a data source. The solution to SQL injection is all about ensuring the quality and validity of inputs.
“The best thing you can do to tighten up your API security profile is to sanitize inputs and do a very rigorous schema-based evaluation of all the inputs coming into your organization,” Morrison said.