BOOK THIS SPACE FOR AD
ARTICLE ADHello Hackers, I Hope you guys are doing well and hunting lots of bugs and dollars !
Today’s article is all about the pentesting approach for APIs. Let’s dive into it.
what is an API?
An application programming interface (API) is a connection that allows computers or software programs to communicate with one another.
It is a form of software interface that offers services to other applications.
It is a software bridge that allows two apps to interact with each other.
As far as we know, APIs communicate with third parties and provide services without exposing a significant amount of sensitive internal data. The main goal of an API is to share only the data or services that are required by a third party without revealing any sensitive internal data in order to improve usability.
We must take care of security at this point, as it is a critical infrastructure. Let’s take a deep look further into the approach for an API’s security assessment process.
The very first step is to understand the scope of testing and its functionality. In general, documentation for the API is available on the internet, with all of the necessary details listed. However, it may not be applicable to all scenarios, thus it is best to understand it on your own or approach the developer for a walk-through (only applicable to white box pentesting) for the same.
Now, Open Postman or any other tool, import the API environment, and integrate it with your proxy tools such as OWASP ZAP, or Burpsuite and you’re ready to go. Go with the same flow as what you do in your web app pentesting.
Practicing recon (understanding the flow, usages, and fuzzing) will be very useful for you in this API section, and then you must perform relevant attacks based on the scenario.
Let’s quickly get into OWASP API Top 10 - 2023 Security Risks.
Broken Object Level Authorization (BOLA): Exploitable flaws in access control mechanisms allow unauthorized users to access specific resources (objects) within an API. Imagine a user modifying an ID or unique identifier in a request URL to access another user’s data.Broken Authentication: Weak authentication protocols (e.g basic authentication) or misconfigured authentication mechanisms (e.g weak password policy, Lack of Bruteforcing protection, Disclosing authentication token or password in the URL, password hashing) enable attackers to steal credentials or exploit vulnerabilities to impersonate legitimate users (Bypassing authentication).Broken Object Property Level Authorization: APIs might expose more data than intended within a response. This can be exploited if access controls are only applied at the object level, allowing unauthorized access to specific data properties within the object. Imagine a user profile API returning a home address or Card Details even though the user only requested basic contact information.Unrestricted Resource Consumption: Sometimes, APIs can get bombarded with too many requests, which can lead to Denial-of-Service (DoS) attacks or high financial loss (Third Party services). This can happen if there aren’t proper limits on the number of requests or if the resource usage quotas are not enough.Broken Function Level Authorization: The design of some APIs may not effectively limit access to certain functions (specific actions offered by the API) based on user permissions. As a result, unauthorized users can perform actions that they are not authorize to, which could lead to unauthorized modification or deletion of sensitive data.Unrestricted Access to Sensitive Business Flows: Critical functionalities within an API (e.g Processing financial transactions, administrative actions) are exposed without proper access controls. This can lead to unauthorized manipulation of core business processes. This vulnerability is a Business logic flaw and could be anything which has significant impact on the business.Server-Side Request Forgery (SSRF): Server side request vulnerability occurs when an attacker can manipulate the input to API that triggers a request from the server to a remote resource. The attacker can then use this to make requests to internal systems or other external resources, potentially gaining access to sensitive data or even taking control of the server itself.Security Misconfiguration: Improper configuration of servers, databases, or the API itself can introduce vulnerabilities. This occurs when servers, databases, or APIs are not set up correctly, leaving the door wide open for attackers to walk in without any resistance. Common examples include using outdated components, keeping default settings, misconfigured CORS, misconfigured HTTP methods, and missing security headers.Improper Inventory Management: Lack of awareness or incomplete documentation of all APIs within an environment makes it difficult to identify unmaintained or unused gateways and secure them. This creates blind spots for attackers to exploit. it easier for attackers to exploit APIs and gain access to sensitive data and infrastructure. For example, Getting access to sensitive data through a publically exposed UAT environment because maybe it has not had all the security patches or implementations.Unsafe Consumption of APIs: Integrating third-party APIs without proper security considerations can introduce vulnerabilities. This includes using APIs with known security flaws or failing to validate and sanitize data received from external APIs.Let me summarize the whole API Penetration testing steps :-
Understanding the scope and attack surface :- This is a vital step in which you must understand your limitations and what you should really test. In the broad sense, this should always be the first step; you should always understand the API functionality and how this particular thing works. This will help in creating a mind map for attacking the surface.
You should initiate it as a normal user and understand the flow of functions.
Keep an intense eye on each response and request while using as a normal user. Then attempt to abuse the API’s features and functionalities.
Let’s have a look at methodology :-
Information Gathering / Recon :- Most of the time you will get documentation (Search on the Internet) of a particular API and that will be very helpful for understanding Architecture ( SOAP/ REST/ GraphQL ). Understanding architecture will give you a brief idea of vulnerabilities to test.
After this enumerate the end-points, Methods and objects by using any fuzzing tool (Param-miner, ffuf, Burpsuite).
I would like to recommend you guys a checklist, which is very useful for me. You can also prefer going with your own checklist.
https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d#file-list-of-api-endpoints-objects
https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content/api
Attacking :- Now, I believe if you have an idea about web pentesting then this will be easy task for you. Because we gonna use the similar technique but you need to keep OWASP TOP 10 API vulnerability in your mind. Let me give you a quick overview for the same.
Authentication :- Check what kind of authentication is used by the application, it can be Basic authentication, token based authentication, JWT authentication, OAuth. Implement the relevant test cases for specific authentication methods. Additionally, verify the authenticity of tokens, and try removing header or authentication values.
Authorization :- Understand the flow of permission and authorization pattern of the application and try to abuse it. look for IDOR, Privilege escalations and other Broken access control bugs.
Information Leakage :- Check if the URL contains sensitive data like passwords, and tokens or displaying internal sensitive data while throwing errors or excessive information in plain text.
Rate limiting :- Check if there is any bruteforce protection is implemented or not. It is not required that at every endpoint rate limiting should be implemented, it should only placed on sensitive actions. Note- Sensitive action will always depend on the nature of API and Be careful while testing rate limiting might accidentally launch a DoS attack, which can make the services down.
Injection :- Check how API is handling the user’s input, is it performing filtration or sanitisation? Test for SQL injection, Cross-site scripting, Command injections, XML injections, Open redirection and other injections.
Content Validation :- Try changing the body content and see how it responds. If it accepts different content, try to escalate it. We can use the Burp extension to convert content from XML to JSON or JSON to XML. If the content type isn’t checked, it could end up accepting malicious data.
Security Misconfiguration :- Is CORS set up correctly? How does error handling work? Are the right security headers in place? What kind of HTTP verbs can we use, and are they safe?
Be sure to explore these top-notch resources for API security. https://github.com/arainho/awesome-api-security
https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/web-api-pentesting
Hope this is useful for you guys
Happy Hacking !
Twitter handle :- https://twitter.com/Xch_eater