October 4th, 2013

Can Your API be BREACHed?

Secure APITLS and SSL form the foundations of security on the Web. Everything from card payments to OAuth bearer tokens depend on the confidentiality and integrity that a secure TLS connection can provide. So when a team of clever engineers unveiled a new attack on SSL/TLS – called BREACH – at July’s Black Hat conference, more than a few eyebrows were raised. Now that it’s Cyber Security Awareness Month, it seems like a good time to examine the BREACH threat.

There have already been a number of articles in the technology press identifying threats BREACH poses to traditional Web sites and suggesting ways to mitigate the risks but it is important for us to examine this attack vector from an API perspective. API designers need to understand what the attack is, what risks there are to Web-based APIs and what can be done to mitigate the risks.

The BREACH attack is actually an iteration of  a TLS attack named CRIME, which emerged last year. Both attacks are able to retrieve encrypted data from a TLS connection by taking advantage of the way data compression works in order to guess the value of a confidential token in the payload. While CRIME relied specifically on exploiting the way TLS-based compression works, the BREACH exploit can target messages sent with compression enabled at the HTTP/S level, which may be much more widely enabled in the field.

HTTP compression is based on two compression strategies for data reduction: Huffman coding and LZ77. The LZ77 algorithm accomplishes its goal of data compression by identifying and removing duplicate pieces of data from an uncompressed message. In other words,  LZ77 makes a message smaller by finding duplicate occurrences of data in the text to be compressed and replacing them with smaller references to their locations.

A side effect of this algorithm is that the compressed data size is indicative of the amount of duplicate data in the payload. The BREACH attack exploits this side effect of LZ77 by using the size of a message as a way of guessing the contents of a confidential token. It is similar in nature to continually guessing a user’s credentials on a system that provides you with unlimited guesses.

While the premise is scary, the good news is that the BREACH attack doesn’t give an attacker unfettered access to the encrypted TLS payload. Instead, it is a targeted attack that attempts to retrieve a confidential token through repeated and iterative guesses. In fact, the attack isn’t an exploit of the TLS protocol at all, rather it is an attack that can be applied to any messaging system that uses the gzip compression algorithm (which is a variation of LZ77).

On top of this, BREACH is not an easy attack to pull off. A would-be BREACHer must:

  1. Identify an HTTPs message which has compressed data, a static secret token and a property that can be manipulated
  2. Trigger the application or server to generate many such messages in order to have a large enough sample size to iteratively guess the token
  3. Intercept all of these messages in order to analyze their sizes

Each of these requirements is non-trivial. When combined, they greatly reduce the attack surface for a BREACH attack in the API space. While API messages certainly contain data that may be manipulated and while many APIs do provide compressed response data, very few of those API messages also contain confidential tokens.

But designers of APIs shouldn’t dismiss the possibility of being BREACHed. There are at least two scenarios that might make an API susceptible to this attack vector.

Scenario 1 – Authentication & CSRF Tokens in Payloads:
Many APIs return an authentication token or CSRF token within successful responses.  For example, a search API might provide the following response message:

<SearchResponse>
    <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
    <Terms>…</Terms>
    <Results>…</Results>
</SearchResponse>

If this response message was compressed and the attacker was able to coerce a victim into sending many requests with specific search terms, it would only be a matter of time before the AuthToken credential was retrieved.

Scenario 2 – Three-Legged OAuth:
APIs that support the OAuth 2 framework for delegated authorization often implement CSRF tokens, as recommended in the OAuth 2 RFC. The purpose of the token is to protect client applications from an attack vector in which a client can be tricked into unknowingly acting upon someone else’s resources (Stephen Sclafani provides  a better explanation of the CSRF threat here.)  Due to the fact that CSRF tokens are reflected back by the server, the three-legged OAuth dance becomes a possible attack surface for BREACH.

For example, an attacker could coerce a victim to send repeated OAuth 2 authorization requests and utilize the state parameter to guess the value of the authorization token. Of course, all of this comes with the caveat that the OAuth server must be compressing responses to become a target. The fact that a new authorization code is generated for each authorization attempt would make this attack less practical but still theoretically possible.

Ultimately, the simplest way to mitigate the BREACH attack is to simply turn off compression for all messages. It isn’t hard to do and it will stop BREACH dead in its tracks. However, in some cases, designers may need to support compression for large data responses containing non-critical information or because they are supporting platforms with low bandwidth capabilities.  In these instances, it makes sense to implement a selective compression policy on an API Gateway.

While disabling compression will certainly negate the impact of the BREACH attack, a more general solution is to impose smart rate limiting on API requests. This will not only negate the sample size that a BREACH attacker needs to guess data, it will also stop other side-effect attacks that don’t rely solely on compression. In addition, log analysis and analytics will make it easier to spot any attempt at an attack of this kind.

An API Gateway is the key component for this type of security mitigation in the API space. A Gateway can provide the level of abstraction needed to enforce configurable compression and rate limiting policies that server side developers may not have the security background to implement effectively. In addition, the Gateway acts as a central enforcement point for security policy – particularly useful in larger federated organizations.

TLS is core to most of the security implementations that have evolved on the Web, including the OAuth 2 framework. This latest published attack does not render the world’s TLS implementations useless but it does introduce an interesting attack vector that is worth protecting against in the API domain. Remember, API rate limiting and usage monitoring are useful for much more than just monetizing an API!

September 30th, 2013

Workshops, Workshops, Workshops!

Layer 7 API WorkshopsOne of the great things about my job is that I get to travel around the world sharing API design strategies, experiences and theories with people who are at the forefront of our industry. These interactions not only make it easier to design effective APIs, they also have the potential to spark ideas that can lead to real business transformation.

But we aren’t all lucky enough to get these types of opportunities and it’s often difficult to justify the cost of traveling to far-flung events in the modern business world. If you’re in that boat, then it’s your lucky day: our Layer 7 API Strategy Workshop series aims to bring all the experiences, discussions and networking opportunities practically to your doorstep.

Over the next two months, Mike Amundsen, Holger Reinhardt and I will be delivering a series of free workshops on API strategy, the principles of good API design and the keys to designing an API that will last. In addition to core aspects of effective API design, we will discuss the emerging trends of developer experience (DX), the Internet of Things (IoT) and DevOps as they pertain to the API universe.

Our tour kicked off in September with great events in San Antonio and Los Angeles and it will continue through October and November with the following stops:

It’s going to be an exhausting couple of months for us but we’re looking forward to having some great conversations with our attendees. So, come out and join us during what promises to be a very thought-provoking and engaging series of half-day events.

September 13th, 2013

Nordic APIs

Nordic APIsIt looks like the remainder of September will provide a bounty of learning opportunities for those of you interested in diving deeper into API design.  To start with, Mike Amundsen and I will be continuing our Layer 7 API Academy workshop tour in Montreal and Calgary. In addition to our API Academy events, Mike will be hosting his annual conference related to all things REST with RESTFest 2013. I had the pleasure of attending last year and I highly recommend going if you are interested in thought-provoking conversation and ideas in the hypermedia domain.

On the other side of the ocean and closer to home for me is next week’s Nordic APIs conference in Stockholm (September 18-19).  I’ve been to a few of the smaller API design conferences that the Nordic APIs team has put on and I can say without a doubt that this will be a conference worth attending.  They’ve always done a great job of putting together sessions that will appeal to developers on the leading edge of API design as well as those who are looking for practical solutions.

I’ll be delivering a keynote presentation on a developer experience (DX) oriented design approach for APIs. My colleague Holger Reinhardt will be talking about the Internet of Things and Aran White will be delivering a demonstration of the Layer 7 product line. Of course, the great value in events like this comes from the serendipitous conversations that take place outside the agenda and Holger, Aran and I are really looking forward to swapping war stories with Nordic API attendees.

While I’m sad that I won’t be able to join Mike at RESTFest this year, I’m overjoyed at the reason I can’t go. I’m continually amazed at how much the European API design community has grown and watching the Nordic event grow from a few small events into a major conference has been eye opening. Not too long ago, it was difficult to find API design events to attend but now we are spoiled for choice. It’s a great indication of the continued interest in and growth of Web-based APIs.

August 29th, 2013

Steering Safely into the Open Enterprise

Tesla Model SI recently wrote an article for Wired, which discussed the importance of thinking about security at every stage of your application lifecycle.  This is especially important as we enter the new era of open enterprise IT. The explosive growth of mobile computing has shifted the enterprise perimeter and traditional access control mechanisms are no longer sufficient. This is even more relevant when thinking about the Internet of Things (IoT) and its rapidly evolving ecosystem.

George Reese of Dell recently published an article that discusses the Tesla Model S REST API.  This API enables some remote control features on the car and is primarily used by Tesla’s available smartphone apps. Great stuff, showing how mobile meets IOT meets API. The problem is that the focus of the article is all on its potential security vulnerabilities. Where the Tesla developers should be lauded for driving this type of innovation, they are instead scolded for addressing security poorly.

I think this is a great example of where thinking about security all through the lifecycle would have saved the developers some embarrassment. Here are some things for them to think about with the next app or API:

  • Are there other clients besides smartphone apps that I want to access my API?
  • Are there other clients besides smartphone apps that I don’t want to access my API?
  • Are there proven standards or protocols I can use to provide access control?
  • Are there proven tools out there that can help me deliver the solution more quickly?
  • Is there a way for me to revoke a client’s access after it has been granted?

The Tesla team chose to take an unproven path with their authentication solution.  “Security by obscurity” used to be a popular approach but it doesn’t cut it in the open enterprise. In open computing, open and popular protocols like OAuth are the most secure mechanisms to use.  That may seem counter-intuitive but these protocols provide the richest set of implementation tools and breadth of use cases. This allows app developers to focus on their areas of expertise – like automotive innovation – and rely on the security experts for protection.

At Layer 7, our products and services help companies build the foundation for the open enterprise.  Our new Mobile Access Gateway release provides a variety of security capabilities, including smartphone access control and token revocation. Our API Academy helps clients design sustainable APIs that address all aspects of the API lifecycle, including the most practical and comprehensive security protections.

August 16th, 2013

Designing Web APIs – A Candid Conversation

API Design WebinarIt was just over a year ago that we hosted our first API Workshop (for the record, it was July 2012 in Sydney Australia). Since then, I and my API Academy buddies Ronnie Mitra and Alex Gaber have had the privilege to meet and talk with hundreds of developers representing dozens of companies and organizations all over the world. It has been a very rewarding experience.

Along the way, we’ve learned a great deal, too. We’ve heard about creative ways people are leveraging the Web to build powerful APIs. We’ve seen great examples of real-world APIs and learned the practices and pitfalls encountered while maintaining and growing these APIs over time. We’ve even had the opportunity to observe and participate in the process of designing and architecting systems in order to foster creative innovation and long-term stability for the APIs.

In the past year, we’ve collected many examples of best practices and distilled common advice from a range of sources. We’ve also created free API events, conducted dozens of hackathons, webinars, one-day workshops and multi-day API boot camps as ways to share what we’ve learned and help others build upon that advice when creating their own Web APIs. And at every event along the way, we’ve met more innovative people doing great things in the Web API space.

As a way to look back and compare notes, Ronnie and I will be hosting a webinar (Designing Web APIs – A Candid Conversation) on August 22 at 9AM PDT. We’ll look back at what we’ve seen on our travels and talk candidly about such topics as SOAP, SOA, REST, lifecycle management and more. It’s going to be a fun hour of both reminiscing and looking forward to this fall’s workshop series and the future of APIs in general.

Also this August, we’re taking a break from offering public events and using the time to compare notes, assess the advice and examples we’ve gathered and improve our content for the upcoming fall season. Ronnie, Alex and I (and many others here) will be spending many hours this month creating new guidance documents, articles and presentations/videos – all in the effort to share what we’ve learned and help others make a difference within their own organizations.

I hope you’ll join us on August 22 for our Webinar and I hope you’ll keep an eye on our workshop schedule for upcoming events near you. Even if you’ve participated in our open workshops before, you’ll want to come back for the new series. We’re adding new topics, brushing up existing material with new guidance from the field and adding new features to the events.