Experience of Security testing on API’s


This blog post is all about my first experience with Security Testing on APIs. Back in 2013, I was working on a project “XYZ” in Moolya Software Testing. It all started on April 1st of 2013 when Pari, the “Master Shifu” sent me the mail with the details of the project, which is an advanced voicemail service especially for business people who do not want to miss the calls, at busy times. Ok, now what form is the product in? Is it web app/mobile app? No, those were API’s; we didn’t have any idea on APIs. First task was to understand API and its functionality. Learnt about the API from team members and by exploring on the internet. Understood what an API is, why are they there for an app and how they are used in an app?

An API — Application Programming Interface — allows your product to communicate with each other. In this way, an API allows you to open up data and functionality to other developers and to other businesses.

As API’s act as a backbone for any application, in simple words which are of pure technical stuffs which communicate between presentation layer and the database. API’s reside in business layer and we can test them for its core functionality. And testing functionality of the application in this state will help reducing maintenance of the application. This triggered me to test the API for its security, which would result in great impact on the product or the application. And that is where I decided to do security testing on API’s. Now coming back to the project, what are we supposed to test, what are the requirements, why are we testing, scope of testing, etc were some of the questions that arose.

After getting clarity on all these queries, we started testing. The next issue was to understand windows azure. These were not normal API’s but were built on different technology (Windows Azure). Initially we explored about this technology and started testing. Then there was a dilemma in selecting the tools for testing API’s. We have numerous tools for testing API, selecting the best tool which suites the project was difficult. Finally I landed up on selecting SoapUI, which helps in Manual/Automation testing. Continued with API automation, which was my primary task. Meanwhile, I was testing manually for its functionality.  I thought, why don’t I start security testing on API’s? Now the question was how? Where? Now comes the exploration part on testing API for its security. In simple words, how can a hacker misuse API, what are the effective attacks on API? Santhosh Tuppad who is a well-known security tester suggested me with a book called “Hacking web services” by Shreeraj Shah, which helped me in understanding what kind attacks can be done on APIs.

Now coming to the attacks mentioned in the book, some of the attacks were simply great, but most of them were outdated. Where today’s servers are built in such a way, where it can handle these kinds of attacks in the initial stages. Now coming back to the project, First task was to note different type of attacks or vulnerabilities.

While I was reading, Shreeraj Shah’s book on Hacking Web Services, I found out that they were traditional approaches. However, it was helpful in understanding several concepts. The challenge was to learn new techniques or new ways of hacking web services. There started my exploration! Well, I was doing black box testing, it all depends how much Quality we want to bring in with testing as a black box tester. While performing the web services testing, I didn’t actually look into the code of the application (like the White box tester’s do). I tried to cover all the possible scenarios’ using the tool (SoapUI). The “Groovy Script” came into picture when I started performing the check automation of regular testing on API’s. Though it is not necessary to learn Groovy to perform testing, it surely gives an extra advantage over other testers 😉

Tests that I performed to find vulnerabilities,

  • Insecure Direct object Reference

  • Information Leakage and improper error handling

  • Authentication and Certification/Permission and Access Issues

  • Authorization

  • SQL/LDAP/XPATH/OS Command Injection

  • Virus/Spyware/Malware Injection

  • Session/Parameter Tampering

  • Denial of Service/Large Payload

  • Brute-force

  • Data type mismatch/Content Spoofing

  • Information Leakage/Error leakage

  • Replay Attacks

  • Buffer Overflow

  • XML Parsing Attacks

  • Spoiling Schema

  • Complex and Recursive structure as payload

  • Fault Code Leaks/Poor Policies

Learning the basic level of Security on API was fun & easy. To master the same anyone will need to get good grip over basic vulnerabilities. As a starting point for above mentioned attacks, I searched forums & blogs for detailed information.

When malicious requests are executed number of technical layers can be targeted, including,

  • NIC (Network interface Card) and its drivers.

  • Operating System, as it processes the incoming request from the NIC.

  • Target application server that handles the request (for example Apache, IIS, etc.)

Let me explain this in a little more detail on how I could manage to accomplish the task, which is Security testing on API’s.

When I come to think of it – how would I identify security vulnerabilities in the first place? What response would I get back when trying, for example a SQL Injection attack that would allow me to identify that there is security vulnerability? Actually, this wasn’t that easy.

More often I will get an error message back that tells me that the service was unavailable to process the malicious request – this might be a good thing during development but that was one of the situations where I needed to don the hat of the hacker; does the error message tell me something I shouldn’t know about the system? For example which database they are using? Which version? Which language or framework? Maybe it exposes internal IP address? Any of these might be exactly what the hacker is looking for, the information allows them to target specific attacks on your application (there are publicly available databases of known security issues in most software like “Exploit DB”) which in turn might give them the backdoor, what an attacker would have been looking for. It’s something called as “Sensitive Information Exposure” it searches messages returned by application for any information that might expose system details to the hacker – version numbers, software technologies, etc.

Other scenario was tests resulting in a Denial of Service. These are unusual but valuable in the sense that, I found them first and can make sure that they won’t happen again so that the end users using the application are not affected. The actual responses to a Security Test and how to interpret them from a security point of view was one of the major issue which I faced, it requires corresponding system knowledge and understanding to be able report them, that would pin point exploits in responses which helped me the most.

Finally I conclude that,

  • Neglecting possible security vulnerabilities and related issues in your services and APIs can put your data and your business at serious risk.

  • Taking security seriously and building basic expertise around it is an investment well worth making.

  • The core mechanics of most security vulnerabilities are easy to understand, test for, and prevent.