Software QA FYI - SQAFYI

API Security Testing: Think Like a Bad Guy

By: John Mueller

You want to check an API to ensure that it’s secure, but just how do you think like a bad guy intent on breaking your API and potentially into your site? Performing the right sorts of API security testing is essential.

Every day it seems like you see another security issue appear in the trade press. In some cases, the news even appears in the national press for the entire world to see, ruining an organization’s reputation in a manner that can cause failure and bankruptcy. A break-in that exposes user information, especially sensitive information such as credit card numbers, is something that every organization wants to avoid. The only way to avoid appearing in the news in the most negative way possible is to ensure the bad guys can’t access your site through one of the most porous borders imaginable: an API used for application development. Here, I’ll outline some common forms of API security testing so that you can create a custom suite of tests for your own API that will help keep the bad guys at bay.

Understanding Essential Security Testing Issues
Testing your API for potential security issues is absolutely essential. However, simply performing tests isn’t enough—you must perform tests that actually simulate the kinds of attacks that an outsider might try. This means that you must think like a bad guy in order to figure out the kinds of attacks that an outsider might try.

You don’t need to go it alone, however. There are ways to think like a bad guy that don’t involve much more than reading the trade press to determine how other organizations have lost their battle to remain predator free, and by avoiding common errors that the bad guys target most often.

Of course, it’s important to know which kinds of security problems to target and test for as part of your API. One of the most important sources of information is the Web Hacking Incident Database (WHID), which lists the following top contenders for hacking.

SQL Injection (18.87%)
Cross-Site Scripting (12.58%)
Denial of Service (8.06%)
Predictable Resource Location (4.35%)
Unintentional Information Disclosure (4.35%)
Brute Force (4.03%)

Using WHID lets you check out the specifics of most incidents by clicking one of the entries in the Quick Downloads section of the page. Using the Full WHID Data on Google Fusion Tables option is probably the fastest way to go. The statistics also tell you that keeping the bad guy at bay is the responsibility of everyone in the organization, but as a developer, you can knock out the two highest contenders just by creating secure applications and fully testing them.

It’s essential to remember that creating secure software, testing it fully, and even performing mock attacks against it will only keep the average bad guy away. If someone is truly determined to break your security, they will. So, part of what you need to take away from this post is that the need for testing is constant, as is the need for vigilance. Looking for the break-in will let you repair problems before they become front page news.

Thwarting SQL Injection Attacks

The SQL injection attack has been around for a long time. The reason that hackers continue to use it is because the technique continues to work. In addition, the technique is extremely simple, so anyone can use it with ease. Let’s say you have the following statements as part of your application:

txtUserID = getRequestString(“UserId”);
SQLCmd = “SELECT * FROM Users WHERE UserId” + txtUserID;

The command, SQLCmd, looks harmless enough. However, what if the user inputs a value that will always be true, such as 100 or 1 = 1? The command will now return every entry in the Users database. If the database contains user passwords, the hacker has now gained access to every account in your system. In fact, there are many ways that a hacker can use to inject all sorts of terrible things. For example, the hacker may simply decide to tell the database manager to drop the Users database, relieving you of the burden of maintaining it any longer.

Fortunately, there are relatively easy ways to overcome such an attack. All you really need to do is check the incoming data. If you’re expecting a simple number, then verify the user has input a simple number, such as 100. Don’t allow anything but numeric input. You can also limit the length of the input, the kinds of characters used for the input, and so on. For example, if a field is supposed to contain a name, it shouldn’t contain a semicolon. The previous example could have allowed for dropping the database if the user had typed 100; DROP TABLE Users. Note that the user would have had to include a semicolon to make this approach work.

Another common way to avoid problems is to rely on SQL parameters. In this case, you force the database manager to verify that each entry is of the right type for a particular field. In addition, this technique ensures that the text isn’t executed as code. Here is an example of the same code using SQL parameters:

Full article...

Other Resource

... to read more articles, visit

API Security Testing: Think Like a Bad Guy