Insecure API Implementations Threaten Cloud

Web and cloud services allow third-party access by exposing application programming interfaces, but many developers and customers do not adequately secure the keys to the cloud and their data, experts say

Dark Reading
Attackers over the past three years have begun to actively target the digital keys used to secure the Internet infrastructure. Stuxnet’s creators stole code-signing keys and then used them to allow the malware to more easily evade host-based security. An alleged Iranian hacker broke into a partner of registry Comodo and bought Secure Sockets Layer (SSL) keys for major domains to eavesdrop on activists. And unknown attackers stole important information on RSA’s SecureID token, a device that generates one-time keys to strengthen online security.

The unique codes that applications in the cloud use to identify one another could be next, security experts say.

So-called API keys are used by Web and cloud services to identify third-party applications using the services. If service providers are not careful, an attacker with access to the key can cause a denial-of-service or rack up fees on behalf of the victim.

“It was created as a fairly nonauthoritative identifier — it was only there to identify applications or the application’s use of an API,” says K. Scott Morrison, chief technology officer of Layer7 Technologies, a provider of Web security and governance products. “The problem is that developers have started using API keys for stuff that matters.”

The problem is not any inherent weakness in the keys, but that developers use them for security when they ought not, he says. In many implementations, the keys are used to identify users, even though the technology was not meant as a way to authorize access to data. And after expanding the power of the keys, developers do not treat them as critical assets. Instead, companies fail to keep track of the keys, e-mailing them around and storing them on desktop hard drives.

“They shouldn’t be used for anything that matters, but people do. And when they do, they don’t take it as far as they need to,” Morrison says. “It’s kind of the worst of both worlds.”

During a presentation at the RSA Security Conference earlier this year, Morrison stressed the danger in the misuse and mishandling of API keys. The warning was repeated at the recent SOURCE Boston conference by application gateway maker Vordel. An improper implementation that allows simple access to an API via use of a secret key can allow attackers to have unmitigated access if the key can be sniffed out or stolen from an authorized user’s computer, said Jeremy Westerman, Vordel’s director of product management, at the conference.

“There is a need to protect these cloud API keys,” Westerman said. “There is a lot of awareness in the industry about protecting, say, SSL keys … Unfortunately, protecting API keys has not reached that level of awareness.”

Cloud and Web service developers must first follow best practices in opening up their APIs to third parties. In return, third-party developers need to handle the keys in a secure manner and not, for example, encode a nonobfuscated key into an application.

[Microsoft Research report shows how risky single sign-on can be without solid integration and better support from Web service providers like Google and Facebook. See Web Services Single Sign-On Contain Big Flaws.]

Communicating best practices can go a long way to fixing the issues, says Mark O’Neill, Vordel’s chief technology officer.

“The SaaS [software-as-a-service] providers expect you to protect these keys, but they don’t tell you how to protect the keys,” O’Neill says.

Companies that have API keys should treat them as valued assets, he says. The keys should be handled in much the same way as code-signing keys and other encryption material.

API keys were first used by Google, Yahoo, and other early pioneers of Web services. However, as the model moved from standalone sites to Web 2.0 mashups and the companies exposed their services for use by other websites, the weaknesses of API keys quickly became evident. Companies began to implement different schemes for application and user authentication, including OAuth, the Security Assertion Markup Language (SAML), and hashed-based authentication codes (HMACs).

The stronger authentication methods should be used for securing sensitive data, and each token should have a reasonable expiration time. In addition, because secret keys are occasionally exchanged, communications should always be over SSL, says Gregory Brail, vice president of technology for Web technology and services firm Apigee.

“The developer needs to understand the limitations and understand the best practices around implementing API keys,” he says.

Developers should still use API keys, Brail says. They should just use them for their proper function and use other tools as the situation demands.

“I’m not saying that there is nothing that can go wrong here; I’m saying that this is not a reason to throw away your API keys,” Brail says. “They are an important part of your whole security system.”

A popular usage of the Vordel Gateway is to take a legacy SOAP service, and deploy it as a REST API for consumption by mobile apps. Mobile apps can consume REST APIs, but you are unlikely to call a SOAP service from a mobile app. REST-to-SOAP conversion is very simple to achieve using a Gateway, because the Gateway can expose REST APIs which map to SOAP services, dynamically creating the SOAP request based on the REST API call.

In the video below, you can see an Android app running in the Android emulator, which is calling a REST API on the Vordel Gateway. At the Gateway, you can see the REST API request is being dynamically converted to SOAP. All without writing any code

When you zoom in, you can see the steps which convert the REST API to the legacy SOAP service call:

Originally posted on http://www.soatothecloud.com/2012/04/mashing-up-salesforce-api-with-cdynes.html, on Monday April 10th 2012, by Mark O’Neill, CTO at Vordel

One of the neatest things about the standard Vordel evaluation/training VM is that it ships with an mashup of the SalesForce API with CDYNE’s EmailVerify API. This example Vordel Gateway circuit is run from a simple Web form, which is shown below. It is based on a scenario where an organization has an existing internal CRM, and they want to broker the data out to SalesForce.

Once the Web form is submitted, it hits maps to a circuit on the Vordel Gateway which first calls out to the EmailVerify API to verify that the email address in the form is valid.

So, here is the form which is submitted. I’ve entered info for a user called “Joe Demo” here in Boston. Note that I had to give him a valid email address (my own email address!) because the EmailVerify API really does validate the email address and so “joe.demo@example.com” would be blocked.

In the Real-Time Monitoring on the Vordel Gateway, we see the API calls out to the SalesForce login service (to get a SalesForce Session which the Gateway then caches), the EmailVerify API, and SalesForce’s API itself, which we use to register the data from the form as a new lead in SalesForce.

And, sure enough, “Joe Demo” is now in SalesForce:

How does this work? If we look at the circuit in the Vordel Policy Studio, we see that the mashup of the EmailVerify API with the SalesForce API is done using simple “drag-and-join” configuration. No coding is required. As well as connecting to the two APIs, we are also enforcing an SLA over the connection to SalesForce, as you can see. Notice also how we are caching the SalesForce SessionID.

An interesting aspect of the SalesForce integration is the protection of the API keys used to access SalesForce. Notice how the Vordel Gateway encrypts all of the SalesForce credentials, as shown below. Vordel is a member of the Cloud Security Alliance and has provided guidance on the CSA blog about protection of API Keys. This is how we do it in the Vordel Gateway:

If you want to get your hands on this demo yourself, and experiment with brokering and mashing up SalesForce and other APIs, contact us.

Deploying Web 2.0 Safely-Application Firewalling Of A REST Web Service

This screencast demonstrates how Vordel XML Gateway is used to safely deploy Web 2.0-based Rich Internet Applications (RIA). In this hands-on demo, an RIA running in the Firefox browser dynamically connects to a REST Web Service using the XMLHttpRequest (XHR) object.

Enabling an API Portal with Vordel. In this video we see how the Vordel API Gateway provides the building blocks which customers use to create an API Portal.

API Gateway support for HATEOAS

I often think it’s ironic that while the mission of REST is to simplify Web development, REST itself is beset with seemingly complex jargon and architecture patterns. I say “seemingly complex” because, once you look into REST architecture in depth, it actually is simple. In some ways, it’s almost too simple. It’s easy to rack your brains about some REST pattern, but then realize: It’s just how the Web works. I’m reminded of the line from Moliere about the bourgeois gentleman who spends years trying to understand how he could speak in “prose”, then he exclaims “Good heavens! For more than forty years I have been speaking prose without knowing it”. So it is with REST. HTTP verbs, URLs, and resources are just what we’ve been doing for years.

There are various levels of REST though, most famously categorized in the Richardson Maturity Model. At the top of this maturity model is HATEOAS. Actually I think “maturity model” is a bit of a misleading name, because ideally you don’t want to start with a very brittle URL and then “mature” it to HATEOAS, since that puts undue requirements onto your client applications. It is better to start with HATEOAS principles from the start.

But what is HATEOAS (and how do you pronounce it?). Well, it stands for Hypertext As The Engine Of Application State. As with everything REST, the concepts come from Roy Fielding’s paper. The core idea is that the HTTP server serves out links which guide the client as to what they can do with a particular resource. So, for example, if I do a GET on a product listed in a catalog, I receive back a series of links which are the actions I can perform on it. I may be able to get the price of the product via one of the links, order it via another link, get back a description of it via another link, or get back its weight via another link. My application may also may be provided an “up” link back to the main list of products. The powerful concept is that the links are all the actions my app can take on the resource. So, if I am not allowed to order the product, then I will not be given the “order” link. The client app can then take this into account (“I wasn’t served up the “order” link for this particular product, therefore I will not provide the user with the ability to order it”). If you can order it, and do order it, then you may not be served up the “order” link for that product anymore, but (because you’ve ordered it) you may be served a link to view your order. This is the stateful aspect (it “knows” you’ve placed the order, and in fact that information is conveyed by the hypertext itself).

Another example is iteration through a set (for example, a list of products). As I am returned back each batch of results (e.g. the first 50, the next 50, etc), I get back a link to the previous batch of results (unless it’s the first batch, then there is no “previous” link provided) and to the next batch (unless it’s the last batch, then there is no “next” link). In this case also, all possible links are provided back to me. So it is also stateful (when I am on the second batch of results, it “knows” to give me link back to the first batch).

Providing all possible links, right inside the hypertext response, is a powerful concept. It’s very different from the SOAP/WSDL world, where you must look at the WSDL in order to find out what actions (operations) are available to you. With HATEOAS, there is no “WSDL”, instead the possible actions are in the response. The SOAP analogy would be where each SOAP response contained a WSDL that listed all of the subsequent operations the client could invoke. Another way HATEOAS is different is that, in the SOAP/WSDL world, if the WSDL changes, then SOAP/WSDL client apps must often be rebuilt. With HATEOAS, the service provider can add another capability, and it comes back as a new link in the hypertext responses, but this does not “break” anything. Similarly, removing a capability translates to removing a link, which should already be handled gracefully by the application.

With HATEOAS, the (hypertext) responses guide the client through their interaction with the resource, by providing links to the actions they can perform, so therefore the hypertext pages themselves become the engine of state. Hence the term, Hypertext As The Engine Of Application State.

[ Regarding pronunciation of HATEOAS, I've heard it pronounced like a breakfast cereal or chip snack ("hate -o's") and also I've heard the edgier "hate yo' ass". ]

So, how does an API Gateway cater for HATEOAS? A key requirement is not to break it. As in medicine, “first do no harm”. Consider what an API Gateway does: It provides external-facing APIs to the public, then translates them to back-end (usually on-premise) API calls.

Take for example the following JSON returned by a server to a client. The client has done a GET to get product information. The response includes a link to order the product, and it also an “up” link to go back to a higher-level view.

{
“id”: “8000″,
“links”: {
“self”: “http://myBackEndAPI:8000/v5/products/123456″
},
“ordering”: [
{
"id": "8000-123456",
"links": {
"self": "http://myBackEndAPI:8000/v5/orders/8000-123456",
"up": "http://myBackEndAPI:8000/v5/8000"
},
"customer_id": "8000",
}
]
}

We see in the response above that the address of the back-end API server (myBackEndAPI:8000) is inside the JSON. When an API Gateway is used, clients go through the API Gateway, and should not go to the back-end API server directly [in fact, usually the API Gateway is cloud-based, and the API implementation is on-premises not directly accessible except through the API Gateway]. Therefore, the API Gateway must selectively replace the address of the back-end API server with the public-facing API server address, and it must do so throughout the responses, whether they are JSON, XML, or another format.

For our example above, the response may become:

{
“id”: “8000″,
“links”: {
“self”: “http://api.mycompany.com/v5/products/123456″
},
“ordering”: [
{
"id": "8000-123456",
"links": {
"self": "http://api.mycompany.com/v5/orders/8000-123456",
"up": "http://api.mycompany.com/v5/8000"
},
"customer_id": "8000",
}
]
}

When requests come back from the client, it must also selectively change this address information, not only in the request URL but also in the payloads being POSTed or PUT to the REST API.

So how is this done? In the case of Vordel’s API Gateway, such content substitution is provided as standard, and is implemented in a high-performance manner so that the URL replacement required to support HATEOAS will not impact on the user experience for your users. Really, what is involved here is analogous to how an application gateway always operates, with the extra stipulation that it must convert information within messages also. But, substituting information within messages is simple with Vordel’s API Gateway, and already widely used such as in simple search/replace scenarios. All of this enables Vordel to support HATEOAS for our API Gateway customers.

Full Visibility of Web Services for SOA Governance How Vordel provides realtime visibility of Web Service performance metrics, message throughput and ensures conformance with Service Level Agreements