Back in January, the API flaw story in Moonpig was described as demonstrative of the poor state of API security.
Sometime later, I had the opportunity to meet Mark O’Neill, vice president of innovation at Axway, whose work focused around API development for mobiles, but with a keen eye on security.
He explained that as mobile apps communicate back with APIs, get data and pull back information that needs to be secured, the business and user needs to be sure that the API itself cannot be compromised.
“With some of the incidents like Moonpig, the whole thing to realise is a mobile app is an API so you can try to compromise the mobile app, or you can go directly to the API,” he said.
“The problem is that there may be an assumption that the API may be called by the mobile app, but if someone can directly call the API and can do scripts and data mining, then the issue is that the API is an afterthought. The bad thing is that companies often have multiple apps, and often have ad hoc APIs and they can be unmanaged and fly under the radar.”
He said that a point Axway discusses and recommends is “API First”, where the idea is that you design and build the API first, secure it and then when developers say “I want to get this data”, you treat the API as a first class citizen and do mobile first.
“There are some standards on development, particularly OAUTH, that can be difficult to implement as it has many different options so becomes complex,” he said. “If you don’t use an approach that is simple then it is possible that somethings will be bypassed on the security side,” he said.
“We recommend that you take a gateway approach where you have a gateway for security and it takes it out of the hands of the developers to manage the consumption of the API, taking the hard problem out of security and put it into the infrastructure.”
I asked him who felt was responsible for flaws in APIs if it is in a poor state of security? He said that if a company has an API that is insecure, it is down to that company and how it is designed. When building the API, he recommended thinking of the attack surface, and think of how it is designed as in some instances, as developers may be naive on input, leave keys in the clear and may leave it vulnerable to man in the middle attacks.
“The classic thing with a mobile app communicating with an API is you set the settings on the phone to go through a proxy on your laptop and you’re going through the same wifi and that goes back to the API, so you may see API keys in the clear and patterns of usage,” he said.
“It is often assumed that the API is going to talk to the app and if you compromise a mobile app, you can say you have just going to look at how it calls as that is where the data is. If you say an app is going after data from an API, that is where the data is and people don’t think about that. APIs could be vulnerable to data mining, but if you have API management in place then you can see evidence of unusual behaviour.”
O’Neill commented that deployment of OAUTH is often insecurely done, and with the introduction of more Internet of Things devices, this development problem could further increase. “So by designing the API first, you are anticipating that there will be lots of things calling it and not only mobile apps, but other things you haven’t thought of,” he said.
He also recommended considering how apps are managed, and see how it is calling the data and detect if there is unusual behaviour and if that is going directly to the API, and apply data masking or obfuscation to the data.
He said: “Some developers are using API keys/certificates to manage the data. They can manage how those are issued and usually we provide a developer portal that customer customise, and it goes through an approval process to ensure the app has access to APIs on a “need to know” basis and only uses certain APIs, and only ones it can use.”
Mark O’Neill, vice president of innovation at Axway, was talking to Dan Raywood
