What Is An API?
API is an abbreviation of Application Programming Interface.
An API is basically a set of commands, and functions that allow us to get access to the information of a website or other external service.
Let’s take the well-known comparison to a waiter – you sit down to eat in a restaurant and choose from the menu, but the kitchen, where your meal is prepared, is in the back- the link that connects you to the kitchen is missing. This is where the waiter, or in our case the API, comes into the picture. The API basically connects the user’s request – which are you, and the person who produces this request – in a restaurant it’s the kitchen, and on the Internet it’s systems.
What Is An API Used For?
For end users, the API allows for efficiency in both development and testing resources.
For API developers, this can offer new services to customers and even make information available in an effective way.
Using the API, it is also possible to allow parties outside the business to gain access to information and perform operations in the business’s computer systems, in a very secure and controlled manner.
Let’s return to the waiter in our example, but this time we will apply it to a more practical case. When searching for a flight, most of us use websites that aggregate the flight details of all airlines – such as Kayak, Skyscanner, and Expedia. These sites do not have direct access to the airlines’ information, which is the information that we as users are looking for.
So they use an API, an interface that helps all travel agency sites get the information from each airline. The API of each airline accesses the data and brings it to the website we have chosen to use, collecting all the relevant information – flight time, destination and origin, available seats, bag policy, and more.
API Vulnerabilities
Bad coding – in other words, human error. If the API code is not coded correctly, the system is more vulnerable to injections and hacks by attackers.
Inadequate validation – an interface can be exploited by a weakness in the website’s protocol. If you notice, when you browse websites, the websites have a prefix of:
- WWW
- HTTP
- HTTPS
Each of these prefixes is actually a communications protocol to the Internet, with HTTPS being the newest and most secure. Any website that uses the HTTPS protocol is required to have an SSL certificate, which is a certificate that confirms that this website uses an encrypted communication protocol between computers. This encrypted communication allows information to pass between two computers, without a third computer being able to understand the passing information. The SSL protocol does not prevent eavesdropping by a third party, meaning it takes into account that there is always someone listening. Rather the SSL encrypts the communications, so any information passed, such as credit cards, log in details, or management of personal areas, cannot be deciphered.
To protect the API make sure the SSL certificate is valid.
Accountability – Who is really responsible for API security risks? The answer starts with the developer. It is the developer’s job to create a secure API. However, the responsibility also falls on the shoulders of the person using the API for their site. People using APIs can add security measures by applying layers of protection such as Cloudflare, which provides WAF services (web application firewall)
Risk of XML – The API interface uses the SOAP protocol, which is a communication protocol designed for the transmission of messages in network services. This protocol uses XML code, a format that has several security risks that can be exploited, if not properly protected.
Lack of security – without security measures such as Transport layer security (TLS) and controlled authentication there is a vulnerable opening for attackers.
User and Password Enumeration – Sometimes APIs “talk” and reveal more information than they need to. In this scenario, when a user sends a request, the API will return information that includes more parameters than required.
Lack of Resources & Rate Limiting – A very common vulnerability is that there is no limit to the number of requests that can be sent. An example of this is a brute force attack where we can retrieve usernames and passwords, or send thousands of requests per second which will cause a DDOS attack.
To perform a brute force attack all a hacker has to do is run a code that attempts to login using all possible passwords. When the hacker has no prior knowledge regarding the password pattern, a.k.a guessing, they start with the shortest passwords and when all options for a password of a certain length are exhausted, the code switches to longer passwords, systematically going through the lengths.
When there is prior knowledge about the password, for example, an anniversary date, it’s possible to run all date combinations systematically.
Hackers can also run the most common passwords.
Luckily, it’s very simple to prevent these attacks. You can limit users’ login attempts, but take into consideration that loopholes are possible
API Pen Test Methodology
Redentry uses the OWASP penetration testing methodology for API Pen Testing in order to deliver a thorough assessment. For more information on the subject: https://owasp.org/www-project-api-security
The tests are done by using a combination of automatic and manual tools, for example:
Burp suite – a wide library of tools for examining an applications system defense, with the main feature being the Burp Proxy, which allows penetration testers to perform a MITM attack – when a hacker places himself between the user and the service provider, either to “listen to the communication” between them or to impersonate one of the parties. The purpose of the attack is to steal personal information – credit card details, passwords, and account information – and usually occurs in communication between users and financial companies, SaaS, online stores, and websites that require account login.
Postman – a tool that allows us to run and simplify the API requests, debugging, and monitoring of the web APIs.
The test includes and covers:
- API performance
- API output- is it delivering the right output?
- Code Security- meeting requirements including controlled authentication, permissions, and access controls.
Rate Limit test where we see if the API is immune to attacks such as:
- Brute Force
- DDOS
- XSS attack
- SQL injections
Common API Pen Testing Findings
Information Disclosure
One of the common mistakes that cause sensitive data leaks- components created in the Test environment return more detailed information from the application, making it easier for developers in the testing process. When you reach the Production environment and these settings aren’t configured accordingly, this can be exploited.
In the following example, we will see how a simple Misconfiguration like leaving DEBUG mode ( Testing mode where the API returns more information) enabled can lead to the disclosure of sensitive information.
When a user makes a request to a user’s endpoint (device), he will receive back the list of users.
But if we execute the same query and add a suffix of _debug to it, we will find that the debug mode remains active and we will get back all the information about the users, including passwords.
If we look at the source code of the application, we can see that the Debug function remained in the code and was not removed as required before exposing the API externally.
API SQL Injection
SQL is a coding language, used to write common features in web applications like search queries, login boxes, and contact forms.
An SQL attack tries to extract information from the site’s database by injecting code into sensitive places on the site such as form and search fields. When performed on an unprotected site can extract information such as usernames and passwords from the site’s database.
In the following example, you can see the source code that is not secure and how it is exposed to SQL injection.
We were able to extract the usernames and passwords with the help of SQL injection, which indicates a vulnerable security system.
Written by Idan Hamo, Cyber Security Analyst
