Utility Nav Menu

Do you know how easy it is for hackers to gain access to server assets by exploiting API (Application Program Interface) calls? Unfortunately, it is quite easy, and as a result, not only public APIs, but also private APIs developed for internal use, are increasingly under attack. In light of recent API-related security breaches, we looked into the security risks associated with API usage and common security practices in place to safeguard the API ecosystem -- which, as it turns out, are not that effective.

Read on to learn more about the security risks associated with server APIs and techniques you can use to comprehensively mitigate these risks. A “Server API” (Application Program Interface) is a set of instructions that applications running on desktops, web sites, mobile devices, or any connected devices as part of the Internet of Things (IoT), use to interact with server-side applications APIs are transforming the way we develop applications and do business.

Make development more like Lego® building – easily integrating numerous shared modules and reducing time-to-market

Enable developers to tap into best-of-breed, “off the shelf” (commodity and complex) functionalities, which they otherwise might have written from scratch. For example, popular APIs support navigation and translation

Are enabling new ecosystems and partnerships

IBM, for example, now allows access to Watson via APIs and thus is opening up access to Watson’s cognitive-computing prowess to millions

Popular apps have integrated payment APIs such as Square, Stripe, PayPal and others to process in-app digital payments

And there are many more examples!

API Usage is Skyrocketing

Given the strategic value of APIs, adoption of APIs is growing at an unprecedented rate

The Centers for Medicare & Medicaid Services, a division of the US Department of Health & Human Services, is introducing policies to make APIs a mandatory industry standard for healthcare interoperability. This requires healthcare providers and professionals to open up APIs as a way to facilitate transmission of sensitive patient data

While APIs offer many benefits, they also introduce new risks that hackers are capitalizing on.

Hackers often use client apps as an attack gateway to back-end servers, by creating unofficial APIs and using them to build unauthorized apps for malicious purpose. This can result in exposing applications and sensitive data on back-end servers. Scott Crawford, Research Director for Information Security at 451 Research, sees that “many organizations are embracing APIs with speed and agility in mobile app development in mind, but if they do not seriously consider the security controls required to secure connections, they may be exposing themselves to more risk than they realize.”

Let’s review an example of a mobile client app that utilizes an API to access functionality residing on a back-end server. The client app on a mobile device communicates to its app server using APIs to authenticate each user and to send/receive relevant data. A hacker who wishes to make his/her own version of the client app can reverse engineer the app and analyze these APIs and implement them in a new app, so the new / cracked-version of the app can communicate with the same servers. The cracked version of the original app may have altered functionality, and/or gain access to the API server for malicious purposes.

How Can You Prevent Unauthorized Access?

The good news is there are steps you can take to secure APIs and protect the “crown jewels” that reside on your servers and are managed by your applications. Authentication is being widely used by most API Management Solutions to confirm that the client app on a mobile device is genuine and authorized to utilize server assets. This is typically done using a simple challenge-response exchange, as the client app tries to connect to the API server. Challenge-response exchange is typically a cryptographic operation, which means that the mobile client generally contains a secret key for an asymmetric cipher like RSA or ECC. The following steps are typically involved in the process:

Client sends “request” for access to the server.

The server performs the cryptographic operation on a random set of data, and sends the “challenge” to client.

Client performs cryptographic operations on server-provided data using its secret key, and sends the resulting data “response” back to the server.

Server authenticates and grants access to the client, if data sent by the client is validated.

Is Authentication Sufficient to Secure APIs?

Most API Management Solutions offer Authentication and Access control policies as the only security measures to secure APIs. These measures act as a good first line of defense, but they are not sufficient. The problem is that a hacker can decompile the original client app and lift the cryptographic key within it, and use the same key in their cloned or cracked version of the original app, in order to pass the challenge-response test. Unfortunately, there are many examples of these type of hacks.

In a hack of a popular messaging service app, thousands of users’ content was stolen and published on 4chan. The company claimed that unofficial, unauthorized 3rd-party apps were responsible for the hack. The company had not released an official API for public use, but that didn’t stop hackers from reverse-engineering the messaging service’s APIs to create unofficial APIs of their own. The unofficial APIs were eventually used to build unauthorized/rogue apps. One developer even posted the unofficial API, which could be used to communicate with the messaging service’s servers! These examples clearly illustrate the need for comprehensive API Security measures, in addition to simple challenge-response based authentication, in order to mitigate APIs’ security risks.

We recommend the following steps:

Step 1: Secure Authentication using White-box Cryptography White-box cryptography is a method for securely hiding cryptographic keys, even if a hacker has full access to the software. The original key material is converted to a new representation using a trapdoor function, which is one-way and non-reversible. This new key format can only be used by the associated white-box cryptographic software, effectively hiding the key. By using white-box cryptographic software, the hacker cannot find the key that is being used for the challenge-response process. However, use of white-box cryptography alone is notenough. White-box cryptography hides keys securely, but a hacker could still decompile the original application, lift out the entire white-box software package and include it in their cloned version of an app. This code-lifting technique is akin to removing the engine from one car and bolting it into another – no specialized knowledge of how the internals of the engine (or white-box implementation in our hacking example) is required.

Step 2: Apply tamper-resistance techniques to prevent code-lifting and app attacksTamper resistance techniques, coupled with self-defense measures, can detect if the white-box software is running in the correct, unmodified application or in a new environment. They also make decompiling an app extremely difficult. Tamper resistance techniques, which also have RASP (Runtime Application Self-Protection) built-in, can respond to runtime attacks with customizable actions and notify app owners when apps are being modified.

Now is the time to realize all the benefits of APIs – and educate yourself on the new risks that they bring! APIs transform the way we develop applications and provide enormous business value to those who take advantage of them. But, if not properly protected with comprehensive security controls, they can also represent a significant risk. When it comes to API protection, comprehensive security involves white-box cryptography solutions augmented by tamper resistance techniques, in addition to basic challenge-response based authentication. In an ever increasingly connected digital world, you don’t want to be the one infamous for your weak connections! To Learn More To learn more about effectively managing application security risk, read our 2016 “State of Application Security” report.