API Testing
APIs can be found in any IT aspect nowadays, from web and mobile applications all the way to IOT solutions and the cloud. It is of paramount importance for a penetration tester to be able to perform a thorough penetration test against an API.
Detection:
Check the path of the API, usually in:
- http://website.com/api/?wsdl
- http://website.com/api/?wadl
- http://website.com/api/v2/<Methodname>
- http://website.com/api/v3/<Methodname>
- http://website.com/graphql
Check for the below headers:
- Content-Type: Application/soap+xml
- SOAPAction:
- Content-Type: Application/json
While Testing:
- Use different methods:
GET
POST
PUT
DELETE
PATCH
- If the application uses JSON try to change it to xml and try xml injection.
- Use content discovery tools.
- Check all the parameters.
- Check API name and version && is it costume or open source.
- Check if there is any online documentation ( in case of open-source API ).
- In case it is white-box engagements, ask the client for the API documentation.
- Add proxy to SOAPUI to ease the testing.
Testing requirements:
(in case it is a white box)
- Ask the client to provide wsdl/wadl documentations.
- If the client implements any kind of authorization (sometimes authorization header) then you need to ask the client to provide Authorization key, or Authorization key, depends on the client environment.
- If the client uses an API for an external entity, you need to have a written permission to test the API.
API Attacks:
1–1 Broken Object Level Authorization
Object level authorization is an access control mechanism that is usually implemented at the code level to validate that one user can only access objects that they should have access to.
How to test:
- Manipulate the data you have to try and gain access to restricted data.
/shops/{shopName}/revenue_data.json → changing the shop name can allow attackers to access different shop data.- Check for any non-default headers, and try to manipulate them
Custom HTTP request header X-User-Id: 54796. Replacing the X-User-Id value with 54795, the attacker receives a successful HTTP response, and is able to modify other users’ account data.
1–2 Broken User Authentication
Authentication endpoints and flows are assets that need to be protected. “Forgot password / reset password” should be treated the same way as authentication mechanisms.
How to test:
There are two sub-issues:
- Lack of protection mechanisms.
- Mis-implementation of the mechanism.
1–3 Excessive Data Exposure
Exploitation of Excessive Data Exposure is simple, and is usually performed by sniffing the traffic to analyze the API responses, looking for sensitive data exposure that should not be returned to the user.
How to test:
Look for sensitive data exposed in the responses of the target.
Sample of the issue is presented in this HackerOne report: https://hackerone.com/reports/723118
1–4 Lack of Resources & Rate Limiting
It’s common to find APIs that do not implement rate limiting or APIs where limits are not properly set. Exploitation may lead to DoS, making the API unresponsive or even unavailable.
How to test:
- Execution timeouts.
- Max allowable memory.
- Number of file descriptors.
- Number of processes.
- Request payload size (e.g., uploads).
- Number of requests per client/resource.
- Number of records per page to return in a single request response.
Uploads a large image by issuing a POST request to /api/v1/images.
/api/users?page=1&size=100. An attacker changes the size parameter to 200 000, causing performance issues on the database.
1–5 Broken Function Level Authorization
Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level.
How to test:
- Can a regular user access administrative endpoints?
- Can a user perform sensitive actions (e.g., creation, modification, or erasure) that they should not have access to by simply changing the HTTP method (e.g., from GET to DELETE)?
- Check access to sensitive methods.
- Check the usage of sensitive requests (OS Commands) — Can be hidden.
- Can a user from group X access a function that should be exposed only to users from group Y, by simplyguessing the endpoint URL and parameters (e.g., /api/v1/users/export_all)?
1–6 Mass Assignment
Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. Attackers can use this methodology to update or overwrite sensitive object’s properties that the developers never intended to expose.
How to test:
Tampering with the request to try and change sensitive values, for example:
- 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.
1–7 Security Misconfiguration
Security misconfiguration can happen at any level of the API stack, from the network level to the application level.
How to test:
- Appropriate security hardening is missing across any part of the application stack, or if it has improperly configured permissions on cloud services.
- The latest security patches are missing, or the systems are out of date.
- Unnecessary features are enabled (e.g., HTTP verbs).
- Transport Layer Security (TLS) is missing.
- Security directives are not sent to clients (e.g., Security Headers).
- A Cross-Origin Resource Sharing (CORS) policy is missing or improperly set.
- Access-Control-Allow-Origin [wildcard — null]
- Access-Control-Allow-Credentials [true]
- Check this HackerOne to understand the issue: https://hackerone.com/reports/426165
- Error messages include stack traces, or other sensitive information is exposed.
- Attack the access token
- Test if the values are predictable.
- Test for no invalidation
- Test for tokens leaked
1–8 Injection
Injection flaws are very common and are often found in SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM. These flaws are easy to discover when reviewing the source code.
How to test:
Refer to the injection attacks in the Input Validation Testing and test each and every relevant attack.
- in case White box:
Use the API documentation to test how the application handles the data, and then start to tamper the requests.
- in case Black box:
Use Burp or any other tool to fuzz the data inputs.
1–9 Improper Assets Management
Lack of assets inventory and retire strategies leads to running unpatched systems, resulting in leakage of sensitive data.
How to test:
Check f Old or previous API versions are running unpatched.
1–10 Insufficient Logging & Monitoring
-in case of White box engagement-
How to test:
Check if the entity does not produce any logs, the logging level is not set correctly, or log messages do not include enough detail.
1–11 Enumerate API Infrastructure
Refer to Enumerate Infrastructure and try to look for any files or directories that does not have a proper authorization and access control.
API wordlists:
- https://github.com/danielmiessler/SecLists/blob/a274ffba577a006213fb2fc80c2325560761a004/Discovery/Web-Content/api/common_paths.txt
- https://github.com/danielmiessler/SecLists/blob/ca6bf04c05447ecfbcc6d99cecb6a7a8bd87f290/Discovery/Web-Content/swagger.txt
- https://github.com/danielmiessler/SecLists/blob/a93ecd7f91a5d8491c7347abf4c1e84fb56b2c2c/Discovery/Web-Content/golang.txt
- https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d
1–12 Configuration Management
There are some security-related HTTP headers that it needs to be set. These headers are:
- Strict-Transport-Security enforces secure (HTTP over SSL/TLS) connections to the server
- X-Frame-Options provides click-jacking protection
- X-XSS-Protection enables the Cross-site scripting (XSS) filter built into most recent web browsers
- X-Content-Type-Options prevents browsers from MIME-sniffing a response away from the declared content-type
- Content-Security-Policy prevents a wide range of attacks, including Cross-site scripting and other cross-site injections
- Access-Control-Allow-Origin [Domain — wildcard — null]
- Access-Control-Allow-Credentials [true — false]
Automated tools:
SoapUI
Step 1 − In the navigator on the left side of the screen, right-click on the “Project” and select “New SOAP Project”.
On selection, a new pop-up window opens -New Soap Project.
Step 2 − Project Name: Enter a project name — it is the user input field. Initial WSDL: provide WSDL URL
Step 3: Leave the default settings and click OK. SoapUI will load the specified WSDL and parse its contents into the following object model:
Step 4: Explore WSDL: Double-click the service in the navigator to open the editor: The Overview tab contains general information on the WSDL file: its URL, target namespace, etc.
The WSDL Content tab provides more details on the WSDL file
After that you can tamper with the requests and test each one of them.
SoupUI Security Testing
1. Create a Functional TestCase (or use an existing one)
2. Add a Security Test
right click the TestCase and select the “New SecurityTest” option, this opens the following dialog:
Select the “Auto” mode to generate default Security Scans and Assertions for the TestSteps in your TestCase and press “Next”:
Here you see a summary of all the Security Scans and Assertions SoapUI will add to the Security Test, press OK to create the Security Test with the described configuration and open the Security Test window:
3. Run the Security Test
Run the Test by pressing the green arrow on the top left (make sure the target service is running), you will see ongoing progress for each TestStep and configured Security Scans in the Security Test window:
You will see ongoing progress in the main window as the different Security Scans are executed, more detailed information is available in the Security Log at the bottom.
4. Analyze the Results
Check here for unexpected alerts that might indicate a possible security vulnerability in your target service. Double click individual entries to see their actual message exchanges.
Configure SOAP UI to use the Burp Proxy:
There are two ways to this: File->Preferences->Proxy Settings or using the “Proxy” icone
Other tool:
SwaggerUI
Automatic API Attack Tool (not updated)
https://github.com/imperva/automatic-api-attack-tool
how to use the tool:
api-attack.sh -f myapi_swagger.yaml -n test.domain.com -s https
-f, — specFile=specFilePath The API specification file (swagger 2.0) to run on. JSON/YAML format.
-n, — hostName=hostName it can be an IP
-s, — hostScheme=hostScheme e.g: https or http
WSDLer
This burp extension takes a WSDL request, parses out the operations that are associated with the targeted web service, and generates SOAP requests that can then be sent to the SOAP endpoints.
Other Resources:
- OWASP API security top 10
- API Security Checklist
