API Testing

OWASP TOP 10 2019

1. Broken Object Level Authorization:

Unauthorized access to sensitive data. A user can change parameter values to access data or other functionality that should not be accessible like data of other user. Overview: Object level auth is access control mechnaism that validate that one user can access objects that they should have access to. Reason: Check not performed in terms of access to actions user performs. Backend doesn't fully track client's state and relies more on parameters like object ID that are sent from client to decide which objects to access.

2. Broken User Authentication

Any methods that lead to compromise of a user account. This includes methods in the user account recovery endpoints (password forgot/reset), user session tokens forgery, bruteforce of user id/passwd.

3. Excessive Data Exposure

Method: Sniff the traffic to analyze API responses : Look for Sensitive data exposure in the same.

Auto: No as unable to differentiate sensitive data.

Cause: API returns too much data that is truncated by client before presenting to user. At times, sensitive data shared.

4. Lack of Resources & Rate Limiting

Objective is to overload the server by any request means possible. Like DOS attacks, lack of rate limiting on the application causes the server API to be unresponsive/unavailable.

How: Change parameter to send bigger requests, burp turbo intruder to overwhelm with request rate.

5. Broken Function Level Authorization

What: Attacker tries to gain access to API endpoints that should be outside of access. These endpoints might be exposed to anonymous users or regular, non-privileged users

How to Test: Perform deep analysis of the authorization mechanism while noting the user hierarchy/roles, and ask if :

• regular user access administrative endpoints

• user perform sensitive actions that they should not have access to by simply changing the HTTP method

• Can a user from group X access a function that should be exposed only to users from group Y, by simply guessing the endpoint URL and parameters (e.g., /api/v1/users/export_all

Examples: An endpoint to create admin users. An endpoint that leaks sensitive admin data to normal user.

Approach: Simple tryout endpoints of other priviledges with your account. Its another task to find out the sensitive endpoints, if no api documentation at disposal, none the less, its a hit and trial to find apis and see how the interact with you user priviledges.

6. Mass Assignment

Modern application have properties linked to the users objection or to others. Some properties like user.name can be directly updated by users, but some like user.balance should be updated only after payment is verfied, user.isadmin flag can only be set by an admin user, etc. Flaw: If the API endpoint directly converts client parameters into internal object properties, without considering the sensitivity and exposure level to these properties (i.e

Examples for sensitive properties:

• Permission-related properties: user.is_admin, user.is_vip should only be set by admins.

• Process-dependent properties: user.cash should only be set internally after payment verification.

• Internal properties: article.created_time should only be set internally by the application.

7. Security Misconfiguration

Find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system.

Auto: Automated scanning exits for this. Example: Server default configs Sensitive files served on server

8. Injection

Just like injections in webapplications,SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM. Easy to find with source code.

Reason:

• Client-supplied data is not validated, filtered, or sanitized by the API.

• Client-supplied data is directly used or concatenated to SQL/NoSQL/LDAP queries, OS commands, XML parsers, and Object Relational Mapping (ORM)/Object Document Mapper (ODM).

• Data coming from external systems (e.g., integrated systems) is not validated, filtered, or sanitized by the API.

9. Improper Assets Management

Old API are still active, are unpatched and without proper security mechanism in place. Due to lack of asset inventory and retire stratergies. All this makes the old api more susseptible to flaws. Check Wayback machines for old documentation and see if any api endpoints are still running. Change v2 to v1 ; maybe legacy version 1 still active. Look for beta API hosts.

10. Insufficient Logging & Monitoring

Allows attacker to abuse system without being noticed. Without logs and monitoring, lack of visibility increases the time before which the crime is found.