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:
... to read more articles, visit http://sqa.fyicenter.com/art/