Apigee Blog

Protecting users, apps, and APIs from abuse

2012-02-22T06:36:01+00:00

Abusers or spammers are the bad guys looking to make money by getting unsuspecting end users or consumers of online services to interact with malicious content or spam that leads to one or more of the following scenarios:

Eyeballs on spam content that lead to clicks and purchases.
Gathering users’ private information through keyloggers (or other spyware) on the user’s machine or device which is then sold to the highest bidder.
Phishing for users’ private information such as SSN, credit card #, or passwords and selling those to the highest bidder.
Installing malicious software on users’ machines or devices, which in turn steals more of their information or uses their bandwidth or storage for carrying our further attacks.

Any workflow that creates or consumes content, shares or reshares content, sends or receives communications can be vulnerable to attack.

Online attacks almost always contain a "payload" that either delivers the attack or leads the user to another location where the attack is completed. Any time a piece of content is created or consumed or a communication is sent or received, there is an inherent "payload" that is delivered. In the wrong hands, this payload can be malicious.

Blogs can be spammed with comments which contain spam or malware, or which employ phishing techniques that redirect users to other malicious locations on the Internet.

In the same way, users can receive emails that contain spam or malware or other phishing techniques. Users can be redirected to malicious sites in their browser. Users' machines can be attacked and malware (such as adware, spyware, key loggers and viruses) installed which can scrape users’ private information and send it to the abusers.

Thinking about apps and APIs as assets

Apps like APIs can be considered "assets" that can be used to carry out attacks against end users.

APIs (and especially free APIs) provide services that eventually reach other users. Even if an API has a usage cost associated with it, if the return on investment for an abuser for planning and carrying out an attack is higher than the cost of using the API (at scale), even paid APIs can be abused.

Both developers and enterprises have apps that are highly monetizable if abused. App-based attacks fall into the following general categories:

Malicious apps: These apps are written with the sole goal of abusing unsuspecting users who download and install them. With the increasing use of single sign on services and integration of social networks with apps through social network platforms, a user's social network can be used to propagate these attacks.

Well-intentioned apps with vulnerabilities: These apps are not written to be malicious but have vulnerabilities either in their code (e.g. the apps's functionality can be scripted or controlled through hooks provided by the app) or in their business logic (e.g. no throttling of calls from a single user to the back-end system). An abuser can exploit these vulnerabilities to carry out attacks on enterprise APIs or on the end users of the apps.

Well intentioned apps exploited by a malicious user: In this case, an abuser can use some legitimate capability offered by the app as a foundation to carry out attacks that propagate through the end user's social network and spread through further usage.

Protecting your assets

You don't want your APIs or apps used for abuse. It is crucial for both developers and enterprises to protect their “assets”. If an end user develops a perception that a certain app or service is "dangerous", usage declines, growth can be reversed, and revenue and profit suffer.

Remember that abusers are most often out there to make money and if the cost to carry out an attack is less than the value derived from the attack, it will continue to be a sound business investment for the abusers.

Some things that developers can do to protect their apps and end users (and their friends)

Monitor usage of your app and its impact on the users. Build and maintain a proxy for user reputation and models of good and bad behavior in the content of the app.
Enable end users to report suspicious behavior of the app or of other users of the app.
Work with the enterprise or API provider to ensure that your app is not creating suspicious loads on the API.

Some things that enterprises can do to protect their APIs

Build traffic monitoring solutions and models to rate traffic as safe or abusive.
Ensure that any content or communication created or shared through the API is free of malicious payloads.
Invest in mechanisms to report and notify suspicious user and app behavior to the app developers.
Build reputation systems for users, content and IP addresses to be able to quickly classify traffic, users and apps as good or bad OR desirable or undesirable.

Next time we'll look at some of the ways to push back against attackers, including use of quotas, throttling, and so on.

Data Analytics & APIs

2012-02-17T06:18:16+00:00

There's an explosion of developers building mobile and web apps. There's also an explosion in APIs as enterprises adopt API strategies to open up access to their back-end systems to enable developers. As a result, more transactions flow from end users and developers to enterprises increasing reach, revenue, and profit for enterprises.

In this short video, I talk about how to think about analytics as a peer of your APIs and the role analytics plays in having your API strategy succeed.

Every enterprise expects to see increasing rate of transactions (sales, subscriptions, etc.) over time. API-delivered transactions are going to contribute an increasingly larger fraction to this top or bottom line.

For an enterprise that is early in its API journey, a small fraction of total transactions come from APIs.

For an enterprise in a later stage of its API program, APIs contribute a much larger fraction of the total transactions.

For all these companies, analytics on APIs benefit many constituents including developers, API managers, operations teams, and business managers.

For the early adopters - the companies embarking on their API journey - analytics optimize the business of APIs. IT and API metrics like throughput, availability, latency, errors etc. all help improve your APIs which results in an increased rate in the growth of your API strategy.

For the seasoned enterprises, analytics become even more important to optimize the business of the enterprise. Leveraging business-level analytics on APIs -- which products are purchased, which are tagged as favorite, which API resources are most used, etc. -- the enterprises in which APIs already contribute a high fraction of transactions will also see an uptick in the rate and relative contribution of API business to the bottom line.

Irrespective of the phase or size of your API program, your business will benefit from analytics.

OAuth: Implementing OAuth 2.0

2012-02-16T17:55:54+00:00

In a recent OAuth post, we recommended that if your API can require HTTPS, use OAuth 2.0. Otherwise, use OAuth 1.0a.

How should you use OAuth 2.0?

There are three types of credentials in OAuth 2.0.

BEARER TOKEN: This type requires SSL. A bearer token is a big random number. Bearer tokens are easier for developers than OAuth 1.0a because they don’t have to write the signature. This is the most straightforward of the credential types to implement. Use it!

MAC TOKEN: Like OAuth 1.0a, uses signature instead of SSL. The spec is still changing so I recommend that you wait.

SAML: Makes sense if the API Team and the developers really want SAML. The OAuth standards team is working on ways to use OAuth with SAML but that option is still changing. I recommend that you wait to implement SAML.

In short, I recommend that you use bearer tokens, as it is the simplest to implement.

How many legs?

I often get this question – how many legs does OAuth have and how many legs should I use?

Let’s look at the 3-legged and 2-legged terminology that’s developed around OAuth.

3-legged OAuth refers to the fact that there are three entities - a user, a client (application), and a server (service) involved. Both the user and the app have credentials.

2-legged OAuth refers to the case where the OAuth signature method is being used to identify just the application – that is, to identify just the client and not the user. This is often done using SSL. But the OAuth 1.0 signature can be used.

In my opinion, 2-legged OAuth uses only a part of OAuth and 3-legged OAuth is really OAuth.

If your API needs to authenticate users, you should use 3-legged OAuth. It has benefits for the API Providers and above all, it will mean improved security and better end user and consumer experiences with web and mobile apps.

Would love to hear your thoughts or questions over on the API Craft Google groups.

OAuth: Is it worth the effort?

2012-02-15T19:00:30+00:00

In the previous few blog posts, I’ve talked about what OAuth is and when and why I recommend it.

This time, let's explore some of the reasons why OAuth is more cumbersome and complicated for developers than plain passwords as well as some recommendations to help you make the decision between OAuth 2.0 or 1.0a.

Because OAuth eliminates password sharing between web apps, and password storage on mobile devices, and importantly for the sake of your end-users’ experience and security, I believe it is worth the effort.

How many versions of OAuth and which one should you use?

OAuth 1.0 The first "production" version of OAuth 1.0 didn't actually do authentication delegation correctly and as a result, the spec itself had to be patched. No one should be using OAuth 1.0 now.

OAuth 1.0a Not an IETF standard but stable and well understood.
Uses a signature to exchange credentials between client and server. This means that you get API security without SSL (not only is the password never exchanged but the OAuth token is never exchanged – it’s encrypted inside the signature). But coding the signature right is tricky.

OAuth 2.0 Actively under development in the IETF.
It is getting more stable and changes less with each draft – core flows are unlikely to change. Supports a ‘bearer token’, which is easier to code than the signature but requires SSL. However, most APIs should be using SSL by default anyway. Optional specs support signatures, SAML, and so on, but those specs are not yet stable.

The authentication dance is painful

There are a lot of great sites where you can get the details of the OAuth 1.0a authentication flow chart, so I'm not going to tackle that here. It’s not simple. It gets a little simpler with bearer tokens in OAuth 2.0 but because of the security requirements and the fact that you have to exchange identity without a password, it's always going to be a little complex.

Signatures are painful

The good news is that in OAuth 2.0 signatures are optional. You can do SSL and use a bearer token.

As I mentioned above, getting the OAuth 1.0a signature algorithm right is difficult. If you’re going to use OAuth 1.0a, I recommend you use one of the many libraries that are available.

Where do you store the credentials on the client?

There is no magic. You have an OAuth token and secret that needs to be on your mobile device and accessible.

You could encrypt it, but then you need access to the key that decrypts it. You could also break them into smaller pieces.

What should you do?

Be patient. If your API can require HTTPS, use OAuth 2.0 with bearer tokens. (Use the latest draft of 2.0.) Otherwise, use OAuth 1.0a.

It's possible to build an effective API right now using either a current draft of OAuth 2.0 (see Facebook) or OAuth 1.0a (see Twitter).

Bottom line, with your end-users’ experience and security top-of-mind, I believe OAuth is worth the effort.

Next time: Implementing OAuth 2.0

The Anatomy of Apps

2012-02-14T22:07:16+00:00

Thanks to all who participated in last week's strategy webinar:
The Anatomy of Apps - How iPhone, Android & Facebook Apps Consume APIs

Thanks to our speakers @edanuff, @landlessness and @sramji.

Here are the slides and video. We'd love more of your thoughts, insights, or questions on the api-craft forum. Or tune in to the new IRC channel #api-craft.

The Anatomy of Apps - How iPhone, Android & Facebook Apps Consume APIs

View more presentations from Apigee

OAuth: For server-to-server APIs?

2012-02-13T22:35:07+00:00

In my last post, OAuth: Why it's good for API providers, I talked about why I recommend OAuth for API providers when they are exposing APIs for web or mobile apps.

This time, a short follow up to look at a couple of scenarios in which OAuth might not be the best solution.

APIs designed to be used only by servers.

When the only clients of your API are servers, OAuth is not the best solution. Having a separate set of authentication credentials for each app is a nice feature of OAuth, but for server-to-server use, the need to log in securely using a browser gets in the way.

Simply assigning a unique password to each app is probably sufficient. Two-way SSL is another good, albeit cumbersome approach.

I believe that OAuth is unnecessary for APIs that are used by a small number of internal or partner systems, and which are used by servers and not by end users who have passwords.

However, think ahead! If you discover that those APIs that are only accessed by servers today are useful by other types of clients (like web or mobile) tomorrow, then you'll need to support OAuth.

Are there other scenarios for which OAuth is unnecessary or even a bad idea?

Just like the server-to-server scenario, I think that OAuth doesn’t make sense in the following scenarios:

- Anything that requires commercial levels of trust. For example, when your security model requires the capabilities of a PKI infrastructure.

- One-time tokens. OAuth is a lot of complexity and machinery to make one API call.

Bad ideas include creating your own ‘version’ of OAuth or creating something that’s like OAuth but different. Sticking with standards, and focusing your development efforts on creating great apps seems like a better idea than rolling your own security scheme.

Next time: We'll talk about some OAuth complexities, and why it's worth the effort.

OAuth: Why it’s good for API providers

2012-02-08T21:51:17+00:00

In OAuth: The valey key metaphor and OAuth: Flow for mobile apps, we talked about why OAuth is good for users - how it allows users to grant third-parties access to their web services or mobile apps without sharing their passwords.

This time, why OAuth is good for API providers whether they are exposing APIs for web apps or APIs designed for mobile apps.

OAuth means that Web apps that expose APIs don’t have to share passwords.

There are two alternatives

- The security risk of typing your password into every single web app you use – an unacceptable risk!

- Some sort of universal single sign-on mechanism (run by a third party that everyone agrees upon and trusts) – it doesn’t exist!

Therefore, for all web apps that expose APIs to other web apps - we recommend OAuth.

OAuth eliminates the need to store a password on a mobile device adding a layer of security when an API is used by mobile apps built by untrusted developers for a public API.

An OAuth token is hard to guess. It is tied to a particular app and device. It can be revoked without affecting other devices and apps.

OAuth allows the API provider to revoke tokens for an individual user, for an entire app, without requiring the user to change their original password. This is critical if a mobile device is compromised or if a rogue app is discovered.

OAuth future proofs the authentication process. Because users’ browsers are redirected to a place that’s under the control of the API team to get the OAuth token, the API team can control what to do at that point in the workflow.

In other words, OAuth is flexible enough to support any of your company’s specific workflows (think SSL, multi-factor authentication, terms of service, changes to terms of service, and so on…) without requiring a change to the client or server.

Therefore, for APIs designed for mobile and native apps – we recommend OAuth

Next time: OAuth in a server-to-server API scenario.

APIs We Love: DonorsChoose.org’s New API Console

2012-02-08T19:35:44+00:00

APIs We Love: DonorsChoose.org’s New API Console

Today there are thousands of APIs doing amazing things - revolutionizing personal data, exposing powerful cloud services, and transforming the way businesses work. We particularly love APIs that make the world a better place - like the API for DonorsChoose.org, an online charity that makes it easy for anyone to help students and classroom projects in need. We're excited to announce that you can learn, explore and test the DonorsChoose.org API on our Providers Page (now with over 40 APIs!) or in the DonorsChoose.org developer guide. DonorsChoose.org uses Apigee To Go to embed the API Console in their site.

[Screenshot, attached]

The DonorsChoose.org API lets developers help classrooms right from their websites or apps. It has been used by Chevron, SONIC Drive-In, NBC Universal, Starbucks and others to build customized cause marketing and community engagement. Now you can use the Apigee API Console to get started quickly, exploring project listings and integrating donation functionality right into your apps.

Tell us your app plans, send feedback and let us know additional API Consoles you'd like to see - email us at console@apigee.com

Tell us your app plans, send feedback and let us know additional API Consoles you'd like to see - email us at console@apigee.com.

OAuth: Flow for mobile apps

2012-02-08T18:34:44+00:00

In my previous post, I talked about how OAuth allows users to grant third-parties access to their web services without sharing their passwords.

In that previous example, our user (Bob) accessed his Twitter account through the bit.ly web site.

This time, let's look at what happens when Bob is using a mobile app instead of a web app.

It’s pretty much the same for a mobile app as a web app. When you fire up your mobile app and want to access Twitter, you don’t want to have to give the mobile app your Twitter password and store it on your phone.

In the same way as happens for the web app, the phone app opens a browser window and directs Bob to login to Twitter (and authorize bit.ly to use his Twitter account) - using OAuth.

The phone app never sees Bob’s Twitter password.

The phone app uses its OAuth credentials to retrieve credentials for Bob. It stores these locally. In this way,

OAuth allows this one phone app access to the Twitter service on behalf of one user (Bob).

This all happens through your browser. There are both advantages and disadvantages to this:

- The advantage of this is that the app never sees your password.

You don’t have to trust the person that built the app or worry about losing your phone (as much).

If Bob loses his phone, he can log into Twitter and revoke the credentials that Twitter gave the phone app. (A thief cannot uncover the password, only the token.)

- The disadvantage is that the app has to open up a browser window. This possibly breaks the flow of a nicely designed UI for a mobile app.

There are ways in OAuth around this but you eliminate many of the security reasons for OAuth in doing so. Twitter and Facebook for example, have made the choice to have everybody log in through the browser.

Next time: Why OAuth is good for API providers.

Armrest & REST API Design

2012-02-07T16:44:06+00:00

Last week I flew from Doha, Qatar to Brussels, Belgium. The fella in the aisle seat fell asleep before takeoff. The road warrior code of chivalry indicates one should never wake a fellow traveler.

So I stayed in my window seat for 8 hours. After a few minutes it became obvious that my armrest (singular, my neighbor had usurped the other one) was uncomfortable.

Here's a picture of the armrest.

The armrest has many problems. The biggest: you can't rest your arm on it.

If you try to relax, your elbow gets sucked by gravity into the cutout and pinched unpleasantly by hard plastic. If you deal with the pain and fall asleep you will wake to find your ears exploding because you inadvertently cranked up the volume, the flight attendant will be tapping your shoulder asking why you paged him and your reading light will be shining in your dilated eyes.

The Airbus A330-200 in which I was traveling holds 250 people. That's 2,000 man hours of discomfort per flight injected into the universe because of bad design.

So, why does such an obviously bad, pain-inflicting design make it into the world?

Because it cost-effectively solves other, non-customer-related problems! In this case, it is a clever way to store the remote controller while still keeping it accessible to passengers. It’s also done in a way that doesn't require an expensive reworking of the interior: cut off part of the armrest, put a hole in it and reattach on a hinge. Done! In-air multimedia problem solved!

What does this have to do with REST APIs?

Even with the best of intentions, API teams often stop short of doing the right things for their customers. Customers of APIs are application developers. Application developers are smart, busy, and born to suffer (especially Objective-C developers, NSThatsADifferentTopic). But they are also often musicians, gamers and aesthetes. They are attracted to things like truth and beauty. And they are attracted to good, self-consistent API design.

So, why do API teams often stop short of delighting developers? Because the time and cost of learning to do the right things and getting them done often seems prohibitive! At Apigee, we share everything we learn on our blog, twitter @Apigee, YouTube, API Craft on Google Group, and in our webinars.

There's no reason to walk the road to creating a fantastic API alone. If you know of an API or an API team that's not doing things right or is trying to go it alone, please send them to us. We'll get them straightened out.