Ensuring Your API Works

Security is about risk management. Ensuring your API works as anticipated reduces risk by reducing the potential for someone making the API work in a manner you hadn’t considered. Hackers often do their dirty work by looking for ways to make code misbehave—to do something the owner doesn’t want it to do. Using an API safety zone lets you test your code in ways that you normally couldn’t test it without creating problems on the test server. You can perform these sorts of tests to ensure your API works as intended:

• Verify that the correct inputs provide the correct responses

• Use range checks to ensure that the API responds correctly to out-of-bounds data

• Input data of the wrong type to ensure the API sanitizes data by type

• Check data length by using data inputs that are both too long and too short

• Purposely input invalid data that hackers might use, such as scripts, tags, or binary data

• Leave required data out

• Add extra inputs

• Create null data inputs

• Overload the API

• Starve the API of resources

Enabling Rapid Development

Placing your API directly on the server means that you have one copy of the API for everyone to use. Naturally, the second that any of the developers decides to try something radical that causes the API or the server to crash, everyone else has to stop work as well. You want your developers to feel free to experiment because you can be sure the hacker will certainly feel free to do so. Creating a constrained environment where everyone has to play by the rules is almost certain to hide security holes that a hacker will use to breach your server.

Sandboxing helps enable rapid development by making it less likely that the server will crash. If the API experiences problems, you can usually recover quite quickly. The sandboxed environment will also make it quite easy to simulate all sorts of conditions that could occur in the real world, such as a lack of resources or resources that are completely missing. However, you still typically have one copy of the API running, so it’s not quite as free as you can make the development environment.

Using a virtual environment makes it possible for each developer (or group of developers) to have an individual copy of the API. Of course, you use more server resources to make this scenario happen, but the point is that you end up with an environment where no one developer can intrude on any other developer’s programming efforts. Everyone is isolated from everyone else. If one developer thinks it might be a good idea to attack the API in a certain way and the attack is successful (bringing the API or the virtual environment down), those efforts won’t affect anyone else. The point is to have an environment in which developers feel free to do anything that comes to mind in search of the perfect application solutions.

The trade-off to consider in this case is one of resources versus flexibility. The sandboxing approach is more resource friendly and probably a better choice for small organizations that might not have many hardware resources to spare. The virtual environment is a better approach for organizations that are working on larger APIs that require the attention of a number of developers. Keeping the developers from getting in each other’s way becomes a prime consideration in this case and the use of additional hardware probably isn’t much of a problem.

Certifying the Best Possible Integration

A problem with integration testing in many cases is that the testing looks for positive, rather than negative results. Developers want to verify that the:

• API works according to specification

• Functionality of the API matches the expectations for any business logic the API must enforce

It turns out that there are a number of solutions that you can use for integration testing that will also help you find potential security issues. The following sections describe the most popular techniques: sandboxing, creating a virtual environment, using mocking, and relying on API virtualization.

Mocking for integration testing

Some developers use mocking for API integration testing. A mocked API accepts inputs and provides outputs in a scripted way. In other words, the API isn’t real. The purpose of the mocked API is to test the application portion separately from the API. Using a mocked API makes it possible to start building and testing the application before the team codes the API.

The advantage of mocking is that any tests run quite quickly. In addition, the response the application receives is precise and unchangeable, unlike a real API where responses could potentially vary. (A mock doesn’t perform any real-world processing, so there is no basis for varied responses.) However, mistakes in the mock can create false positives when testing the application.

Examples of mocked APIs exist online. For example, if you want to test your REST-based application, you can use Mocky to perform the task. You use Mocky to create a canned anticipated response that an application can query, as shown in Figure 10-1. Mocky makes it possible to create various response types as well. Not only do you control the HTTP response, but you also control the content response type and value.

A number of mocks provide both SOAP and REST support. For example, mockable.io/ supports both SOAP and REST, as shown in Figure 10-2. In order to use this service, you must sign up for an account. A trial account lets you perform testing, but any data you generate isn’t private. In order to create a private setup, you must obtain a paid account.

Figure 10-1. Mocky provides a simple form you fill in to configure testing

Figure 10-2. Use mocks such as mockable.io when you need SOAP support

In this case, once you select the kind of mock you want to create, you fill out a form to perform the actual testing process. As shown in Figure 10-3, the list of settings you can change for the mock is extensive. In this case, you also select items such as the verb used to create the call. The point is that a mock provides an environment where you provide a specific input in a specific way and get a specific result back.

Figure 10-3. Some mocks provide a significant amount of control over the testing interface

The more advanced mocks, such as Apiary, offer a range of services to make the mocking process easier. You can use this service to generate documentation, integrate coding samples, perform debugging tasks, and automate testing. Naturally, as the complexity of the mock increases, so does the price.

Integrating using API virtualization

A sandbox environment makes it possible to do something that you normally couldn’t do easily—virtualize a missing API. It’s entirely possible that your development schedule won’t match the schedules of some of the third parties you depend upon for services. When this problem occurs, companies are often left twiddling their thumbs while waiting for the dependent API. Of course, you could always reinvent the wheel and create your own version of the API, but most organizations don’t have that option and it really isn’t a good option even when you do have the resources.

Note

Never confuse API virtualization with server virtualization or the use of virtual machines. In the latter two cases, you create an entire system that mimics every part of a standard platform as a virtual entity. API virtualization only mimics the API. You couldn’t use it to perform tasks such as running an application directly.

Virtualization is the process of creating a representation of an API that you can use for testing and other purposes. The representation acts as a sort of black box that you can use in lieu of having the actual API to rely on. This black box ultimately provides access to the actual APIs, but it could also provide access to a mock instead. The point is that the API virtualization layer provides a consistent means of interacting with the API and integrating an application with it, even if the API isn’t completely finished. Figure 10-4 shows how the API virtualization layer looks.

Figure 10-4. The API virtualization layer separates the application from the APIs

Using API virtualization hardens your application against the sorts of failures that hackers love. The virtualization layer makes it possible for the application to continue running even when the API itself isn’t functioning correctly. For example, you could create a mock to stand in for the API when a failure occurs and the application will simply continue running. The user might not even notice any difference. Later, when the API is back online, you can perform any required recovery in the background. The point is that a hacker won’t be able to get the application to fail simply by overloading the API.

In some cases, you can create an even better environment by combining a sandbox product with API virtualization. For example, SmartBear provides two products: VirtServer and Ready API!, that make it possible to create a two-layer approach to working with APIs (read more at http://smartbear.com/product/ready-api/servicev/features/share-virtual-services/). The idea is to gain additional flexibility in working through complex  API interactions.

Verifying the API Behaves Under Load

Load testing is important for security reasons because hackers often overload an API or an application in order to cause it to fail in a specific way. After the API or application fails, the hacker uses various tricks to use the disabled software as an entry point to the network. Consequently, knowing how your API will degrade when loaded is essential because you want it to fail gracefully and in a manner that doesn’t open huge holes for the hacker to enter. It’s essential to keep in mind that every API is going to fail at some point if you put enough of a load on it. Despite promises you might have read in the past, there isn’t any way to make software scale to the point it can accept an infinite load (assuming that it’s even possible to test for such a thing).

In order to perform load testing, you must be able to simulate a load, which usually means adding software to the system that will make the required calls, reduce resources as needed, and perform any required logging. Most developers use a sandboxed environment for load testing because it provides the most realistic testing environment. Look for tools that work with all the platforms you need to support. Some products, such as LoadUI, provide versions for Windows, Mac, and Linux testing. Before you get any tool, try to download a trial version to see if it works as promised.

A starting point for any API load testing is determining how to test it. You need to obtain statistics that tell you how to load the API to simulate a real-world environment. To ensure the API works as advertised, you need to determine:

• Average number of requests the API receives per second

• Peak number of requests the API receives per second

• Throughput distribution by endpoint (the locations that make calls to the API)

• Throughput distribution by user or workgroup

It’s also important to decide how to generate traffic to test the API. You may decide to start simply. However, it’s important to test the API using various kinds of traffic to ensure it behaves well in all circumstances:

• Repetitive load generation (where the testing software uses the same request sequence)

• Simulated traffic patterns (a randomized version of the repetitive load generation or a replay of API access log data)

• Real traffic (where you have a test group hit the API with real requests)

After you establish that the API works under standard conditions, you need to vary those conditions to simulate a hacker attack. For example, a hacker could decide to flood the API with a specific request, hoping to get it to fail in a specific manner. The hacker could also decide to keep adding more and more zombies in a distributed denial-of-service (DDoS) attack that simply loads the API down to the breaking point. Get creative. It’s important to determine what will break your API and cause it to fail, and then see how the API fails. Knowing how the API will fail will help you determine the level of risk that each kind of hack poses so that you can better prepare for the consequences.

Keeping the API Safe from Hackers

After you have performed all of the other testing described in this chapter, you might think that your API is safe. The problem is that you haven’t thought about all the ways in which the hacker will attack it. If someone is truly determined to break your API, they’ll find a way to do it. Chapter 9 discusses the need to think like a hacker. Of course, that’s a good start, but once you have ideas on how someone could break your API, you need to test them. The only way you can do that safely is to try creating an API safety zone.

In this one case, testing with both a sandboxed and a virtualized environment will help you get the best results. Each environment provides specific advantages to the tester that will help ensure the API will behave itself in the production environment.

Using an Off-the-Shelf Solution

Building your own sandbox could be a lot of fun, but it’s more likely a waste of time. You want to focus on your application, rather than build an environment in which to use it safely. That’s why you need a good off-the-shelf solution that you can trust. The following list describes a few of the available sandbox solutions:

AirGap

This is an interesting idea. Instead of allowing the browser to run on the client system, it runs on a server in the cloud. The user relies on a viewer application that provides isolation from the browser. You see the browser window and interact with it as you normally would, but the only thing that is running on the client system is the viewer. The vendor promises physical, connection, session, and malware isolation using this approach. You’d need to try it with your application to see if the viewer approach would actually do the job.

Warning

A solution such as AirGap works fine for many users. However, you must consider where the browser is running. If you are in a regulated industry or your application deals with sensitive information, then AirGap won’t work for you. The browser really does need to run on the host system to work correctly and to maintain the confidentiality that the legal system (or common sense) requires.

Sandboxie

You can use Sandboxie to run any application on the host system, not just browsers. This means that you can use Sandboxie to perform all sorts of tasks that other solutions might not support. Because it runs on the client system, all your sensitive data remains fully protected from view. The vendor provides a trial version you can test. When you choose to buy a license, you have a choice between a home and small business version or an enterprise version. Only the enterprise version comes with a support package. Sandboxie only works with the Windows operating system.

Spoon.net

Sometimes you need to test a lot of different browsers, but downloading and installing them all on your system is difficult. Configuring all these browsers as you need them configured adds additional steps. You can avoid all this pain by accessing the browser through the environment provided by Spoon.net. To use this product, you install a plug-in for your browser and then choose the browser you want to use, as shown in Figure 10-5. The browser selections aren’t limited to those that your platform would normally support. For example, even if you’re using a Windows system, you can load Safari or Firefox Mobile to perform required testing.

Figure 10-5. Spoon.net makes it possible to use any of the most common browsers

Using Other Vendors’ Sandboxes

There are situations where you use a sandbox whether you want to or not. For example, when writing an application that uses the eBay API, you must first use the sandbox to write your application code and then test it. Only after eBay certifies the application can you run it in the production environment. Because of the high risks involved in the API environment, you will likely find that you spend considerably more time using third-party sandboxes to test your code.

Access to most of these sandboxes relies on specialized keys. Vendors, such as eBay, want to know who is using their sandbox and for what purpose. The key uniquely identifies you and you must have it in order to make a sandbox call. When working with eBay, it’s easy to get the key, create a user account, and then enter the sandbox to begin performing application testing, as shown in Figure 10-6.

Figure 10-6. Most vendors will require some sort of access control to use their sandbox

A problem can occur when you need to use multiple APIs in your application and each of these APIs has its own sandbox environment. Trying to get the application certified means getting each of the vendors to sign off on it. Make sure you create a plan for getting your application signed off by each of the vendors before you begin coding. In some cases, you may have to break your application into separately testable pieces in order to gain the approval you need.

Defining the Virtual Environment

A virtual environment can refer to any software that provides the means to isolate other software. Think about it as you do a container, because that’s what it is. Previous sections of the chapter have described various kinds of virtual environments. However, this part of the chapter describes the kind of virtual environment you use for development purposes, rather than running an application as a user.

The basic reason to use virtualization is to isolate all or part of the development environment so that you can play with the application. Finding security issues truly does mean experimenting with the software in ways that you would never use in a standard operating system (especially not one connected to the network where your mistake could take down everyone).

Virtual environments can also include so much more than a sandbox does. It’s possible to create virtual environments with specific operating systems, development tools, application setups, and browsers. The virtual environment emulates every part of the development experience so that you can create an Apache server setup using one virtual environment and an IIS server setup using another. Both virtual environments can exist on the same machine without any problems with conflicts.

Differentiating Virtual Environments and Sandboxing

Virtual environments and sandboxes have many similarities. The rest of the chapter has described the most common similarities, such as keeping your API safe. The basic differences between most virtual environments and sandboxing are that virtual environments are:

Repeatable

When you move the virtual environment file to another system, that system runs the virtual environment precisely as it would run on the original system. What this means is that every developer sees the application in the same way, using a prescribed development environment, so the results seen on one system are repeatable on another system. Differences between setups make it hard (sometimes impossible) to verify the presence of security issues.

Movable

Depending on the virtualization software you use, you could move the virtual environment just about anywhere. As long as the developer receiving the virtual environment file has the correct software, it’s possible to re-create the precise virtual environment needed to work with the project.

Recoverable

Virtual development environments rely on a special kind of file that defines how to create the required emulation. If your experiments cause the virtual environment to crash, all you need to do is close that copy of the virtual environment and start another. Recovery takes only as long as needed for the software to load, which may be just a few seconds.

Re-creatable

There are times when you need multiple copies of the same project running on your system. You can create as many copies of a virtual environment as needed for your purposes. The special nature of virtual environments means that every copy you create will begin with precisely the same resources, software loaded, environment, and so on. Consequently, every copy is a clone of every other copy on your system.

Implementing Virtualization

One of the more interesting virtual development environments is Vagrant. This particular product runs on any Windows, OS X, or common Linux system (there are versions of Linux that don’t work with Vagrant, so be sure to check the list to be sure Vagrant supports your Linux distribution). To use this product, you install it on your system, configure the kind of environment you want to use for development purposes, and place the resulting file with your project code. Any time you want to start up the development environment you need for a particular project, you simply issue the vagrant up command and it configures the correct environment for you. The product will create the same environment no matter where you move the project files, so you can create a single environment for everyone on your development team to use. Vagrant is a better choice for the individual developer or a small company—it’s inexpensive and easy to use.

Another useful virtual environment product is Puppet. This product relies on VMware, with Puppet performing the management tasks. The combination of Puppet and VMware is better suited toward the enterprise environment because VMware comes with such a huge list of tools you can use with it and it also provides support for larger setups.

Relying on Application Virtualization

All sorts of virtual environments exist to meet just about any need you can think of. For example, Cameo makes it possible to shrink any application down into a single executable (.exe file) that you can copy to any Windows machine and simply run without any installation. If you need to support other platforms, you can copy the application to the Cameo cloud servers and execute it from there.

Application virtualization is a packaging solution. You create a virtual environment that specifically meets the need of just that application. Figure 10-7 shows how the virtual application environment might appear. As far as the application is concerned, it’s operating in its native environment, even though it’s using a completely different operating system to perform tasks.

Figure 10-7. Application virtualization is a kind of packaging technology

Another product that provides an application virtual environment is Evalaze. This product emphasizes the sandbox environment it provides along with the application virtualization. You can use it to run an application from all sorts of places, including memory sticks. This is a great solution to use if your application requires a specific browser and you want to be sure that the user’s environment is configured correctly.

Researching an appropriate kind of virtualization will take time and you need to pursue your research with an open mind. Some of those odd-looking solutions out there may be precisely what you need to create a secure environment for your application.