I am sure most of you would consider me insane if I say ‘be a hacker’ for your own software. But how many of you will agree that thinking like a hacker is one of the key points that can help to get rid of software attacks. True!
Security issues are not minor and neither are they time bounded, they can occur anytime and any number of times. Security hassles occur almost daily and at times these are on such a large scale that creates a buzz in the news hence resulting in the loss of the organization’s fame.
Looking at this, it becomes essential that we test and protect our softwares to the best of our knowledge, which we definitely do. But where’s the loophole in our testing? What are we missing out? Why do we only perceive the positivities? Can there be a negative bent too? This is where we need to be in the hacker’s shoes and think like them for it is us who best knows the software and all the best combination of testing that needs to be carried out.
The ideal way to avoid negativities is to make sure the hackers are unable to access your site through one of the most porous borders imaginable: an API used for application development. This blog will take you through different forms of API security testing that will help you create a custom suite of tests for your own API and hence shoo the hackers.
Why is Security Testing Essential?
Testing your API for potential security issues is absolutely crucial. However, what we as testers do is merely perform tests ignoring to keep a check on the kinds of attack any third party can go for, therefore it’s imperative to perform tests that actually simulate the kinds of attacks they might try. This is where I justify my statement ‘be a hacker’, think from their perspective to gauge the attacks their minds can plan.
Now the interesting question is how to go about it? There are ways to think like a hacker that don’t involve much more than reading the newspapers to figure out how other organizations have lost their battle to remain predator free, and by avoiding common errors that the hackers target frequently.
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%)
Obstructing SQL Injection Attacks
This attack is a very common one and the most applied technique too as it is very simple to use. 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.
While you design your test, you must include all sorts of errant input to ensure whatever technique (or combination of techniques) you use actually works. For example, a tester may not think to use punctuation marks as input, but a user might. Try entering control characters by pressing ALT+<Three Digit Number>. For example, ALT+000 will enter a null character that can cause some serious problems. Be proactive in your testing and stop assuming that the database manager or other entity will halt an attack.
Manage Cross-Site Scripting
A cross-site scripting attack is one in which your page is infected with a client side script that is then downloaded to a victim. The script executes on the victim’s system and does something wrong, such as causing the victim to give up valuable information or cause the victim system to act lifeless.
For example, many pages include a comments section. A hacker can include a reference to a script as part of a comment on your page. Every user who downloads and reads that comment will also download and execute the script. In this case, you can overcome the problem with proper comment moderation.
However, what happens when your page accepts input arguments that could include a client-side script? In this case, follow the same testing techniques as you would for SQL injection attacks, but within your JavaScript code instead of at the database manager. As with SQL injection testing, you need to verify that inputs are of the right type, the correct length, and within the correct range. In addition, you need to check for telltale signs of hacking, such as errant characters such as semicolons.
This blog has covered coping up with the major attacks, however there are many vulnerabilities that can occur. But the crux of overcoming all the potential holes in your API is to wear the hackers’ shoes and pick up relevant mix and match of testing, site management, and user training. Keep Testing Safe!
Referral: smartbear.com
