Scribd
Upload
7 views

API Testing Checklist

The document provides a comprehensive API testing checklist, highlighting key vulnerabilities and testing strategies for APIs. It emphasizes the importance of testing various authentication methods, identifying potential security flaws, and expanding the attack surface during penetration testing. Additionally, it offers tips on exploiting common weaknesses and utilizing tools for effective API security assessments.

Uploaded by

Chukwuebuka Asogwa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
7 views

API Testing Checklist

The document provides a comprehensive API testing checklist, highlighting key vulnerabilities and testing strategies for APIs. It emphasizes the importance of testing various authentication methods, identifying potential security flaws, and expanding the attack surface during penetration testing. Additionally, it offers tips on exploiting common weaknesses and utilizing tools for effective API security assessments.

Uploaded by

Chukwuebuka Asogwa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Won't Fix!!!

62

API Testing Checklist


By Latish Danawale - July 25, 2020

Checkpoints:

1. Older APIs versions tend to be more vulnerable and they lack security mechanisms.
Leverage the predictable nature of REST APIs to find old versions.
Saw a call to 'api/v3/login'? Check if 'api/v1/login' exists as well. It might be more vulnerable.

2. Never assume there’s only one way to authenticate to an API!


Modern apps have many API endpoints for AuthN: `/api/mobile/login` | `/api/v3/login` |
`/api/magic_link`; etc. Find and test all of them for AuthN problems.

3. Remember how SQL Injections used to be extremely common 5-10 years ago, and you could break
into almost every company? BOLA (IDOR) is the new epidemic of API security.

4. Testing a Ruby on Rails App & noticed an HTTP parameter containing a URL?
Developers sometimes use "Kernel#open" function to access URLs == Game Over.
Just send a pipe as the first character and then a shell command (Command Injection by design)

Reference Link: https://apidock.com/ruby/Kernel/open

5. Found SSRF? use it for:


- Internal port scanning
- Leverage cloud services(like 169.254.169.254)
-Use http://webhook.site to reveal IP Address & HTTP Library
-Download a very large file (Layer 7 DoS)
-Reflective SSRF? disclose local mgmt consoles

6. Mass Assignment is a real thing.


Modern frameworks encourage developers to use MA without understanding the security implications.
During exploitation, don't guess object's properties names, simply find a GET endpoint that returns all of
them.

7. A company exposes an API for developers?


Alt+A
This is not the same API which is used by mobile / web application. Always test them separately.
Don't assume they implement the same security mechanisms.
8. Check if the API supports SOAP also.
Change the content-type to "application/xml", add a simple XML in the request body, and see how the
API handles it.

9. IDs in the HTTP bodies/headers tend to be more vulnerable than IDs in URLs. Try to focus on them
first.

10. Exploiting BFLA (Broken Function Level Authorization)?


Leverage the predictable nature of REST to find admin API endpoints!
E.g: you saw the following API call `GET /api/v1/users/<id>`
Give it a chance and change to DELETE / POST to create/delete users

11. The API uses Authorization header? Forget about CSRF!


If the authentication mechanism doesn't support cookies, the API is protected against CSRF by design.

12. Even if the ID is GUID or non-numeric, try to send a numeric value.


For example: "/?user_id=111" instead of "[email protected]"
Sometimes the AuthZ mechanism supports both and it's easier the brute force numbers.

13. Use Mass Assignment to bypass security mechanisms.


E.g., "enter password" mechanism:
- `POST /api/rest_pass` requires old password.
- `PUT /api/update_user` is vulnerable to MA == can be used to update pass without sending the old
one (For CSRF)

14. Got stuck during an API pentest? Expand your attack surface! Find sub/sibling domains using
http://Virustotal.com & http://Censys.io.
Some of these domains might expose the same APIs with different configurations/versions.

15. Static resource==photo,video,..


Web Servers(IIS, Apache) treat static resources differently when it comes to authorization.
Even if developers implemented decent authorization, there's a good chance you can access static
resources of other users.

16. Even if you use another web proxy, always use Burp in the background.
The guys at @PortSwigger
are doing a really good job at helping you manage your pentest.
Use the “tree view” (free version) feature to see all API endpoints you’ve accessed.

17. Mobile Certificate Pinning?


Before you start reverse engineering & patching the client app, check for both iOS & Android clients and
older versions of them.
There's a decent chance that the pinning isn't enabled in one of them. Save time.
18. Companies & developers tend to put more resources (including security) into the main APIs.
Always look for the most niche features that nobody uses to find interesting vulnerabilities.
"POST /api/profile/upload_christmas_voice_greeting"

19. Which features do you find tend to be more vulnerable?


I'll start:
- Organization's user management
- Export to CSV/HTML/PDF
- Custom views of dashboards
- Sub user creation&management
- Object sharing (photos, posts,etc)

20. Testing AuthN APIs?


If you test in production, there's a good chance that AuthN endpoints have anti brute-force protection.
Anyhow, DevOps engineers tend to disable rate limiting in non-production environments. Don't forget to
test them :)

21. Got stuck during an API pentest? Expand the attack surface!
Use http://archive.com, find old versions of the web-app and explore new API endpoints.
Can't use the client? scan the .js files for URLs. Some of them are API endpoints.

22. APIs tend to leak PII by design.


BE engineers return raw JSON objects and rely on FE engineers to filter out sensitive data.
Found a sensitive resource (e.g, "receipt")? Find all the EPs that return it:
"/download_receipt","/export_receipt", etc..

23. Found a way to download arbitrary files from a web server?


Shift the test from black-box to white-box.
Download the source code of the app (DLL files: use IL-spy; Compiled Java - use Luyten)
Read the code and find new issues!

24. Remember: developers often disable security mechanisms in non-production environments


(qa/staging/etc);
Leverage this fact to bypass AuthZ, AuthN, rate limiting & input validation.

25. Found an "export to PDF" feature?


There's a good chance the developers use an external library to convert HTML --> PDF behind the
scenes.
Try to inject HTML elements and cause "Export Injection".

26. AuthZ bypass tricks:


* Wrap ID with an array {“id”:111} --> {“id”:[111]}
* JSON wrap {“id”:111} --> {“id”:{“id”:111}}
* Send ID twice URL?id=<LEGIT>&id=<VICTIM>
* Send wildcard {"user_id":"*"}

27. BE Servers no longer responsible for protecting against XSS.


APIs don't return HTML, but JSON instead.
If API returns XSS payload? -
E.g: {"name":"In<script>alert(21)</script>on}
That's fine! The protection always needs to be on the client side

28. Always try to send "INVALID CONTENT TYPE" you will end up getting hidden endpoints in
"RESPONSE".

29. Found a GraphQL endpoint?


Send the following query to list the whole schema of the endpoint. It will list all objects and the fields
they have.
{__schema{types{name,kind,description,fields{name,type{name}}}}}

PS: It doesn't work if introspection is disabled.

30. GiHub Dorks for Finding API Keys, Tokens and Passwords
api_key
"api keys"
authorization_bearer:
oauth
auth
authentication
client_secret
api_token:
"api token"
client_id
password
user_password
user_pass
passcode
client_secret
secret
password hash
OTP
user auth

Credits: traceableai, s0md3v, D0cK3rG33k


API

ademmansouri July 25, 2020 at 1:19 PM


that's a treasure to me,
Thank you a lot mate

Latish Danawale July 26, 2020 at 5:49 AM

Glad it helped! :)

REPLY

Anonymous July 26, 2020 at 8:35 AM


A good experience is reflecting here.

Latish Danawale July 26, 2020 at 2:34 PM


Just collated from twitter. All credits goes to traceableai!

REPLY

Enter Comment

Popular posts from this blog

THE PLANETS: MERCURY Walkthrough - VulnHub


By Akshay Pandurngi - October 04, 2020

Introduction Getting back to CTF solving after a looong break, is a difficult task. So, I
decided to proceed with an EASY challenge, and VulnHub was the obvious choice to
find the one. In few searches, I found a perfect machine to start with - 'The Planets: …

READ MORE

OSCP - Personal Notes


By Latish Danawale - August 14, 2020
Hey Guys, in this post I am just going to copy paste my notes which I collected
during my OSCP journey from different sources. Feel free to collaborate. 💀 [*] SSH -
22 Tunneling ssh -L 8443:127.0.0.1:8443 [email protected] Credentials Spraying ncrack -U…

READ MORE

Powered by Blogger

Theme images by Radius Images

Contributors

AKSHAY PANDURNGI

LATISH DANAWALE

Translate
Select Language
Powered by Translate

Archive

2020 (8)

October (1)

August (5)

July (2)

#Bugbountytips

API Testing Checklist

2017 (1)

November (1)
SHOW LESS

Labels
Report Abuse

You might also like