Attacking APIs

https://medium.com/datadriveninvestor/api-security-testing-part-1-b0fc38228b93
https://medium.com/bugbountywriteup/31-tips-api-security-pentesting-480b5998b765
https://github.com/smodnix/31-days-of-API-Security-Tips
https://docs.google.com/spreadsheets/d/1jn3JnWzQFZW41gKo5Fhxwf2ke2w-pvrpCGhBmKhyIBE/edit#gid=0
https://medium.com/@inonst/a-deep-dive-on-the-most-critical-api-vulnerability-bola-1342224ec3f2

# How to use different known APIs
https://github.com/streaak/keyhacks

# REST uses: HTTP, JSON , URL and XML
# SOAP uses: mostly HTTP and XML

# SOAP can be more recommandded in terms of security, if you have to process critical data.

# Test tokens
# Authentication token, JWT, Base64 encoded...

# Input validation
# All entry points (command injection, sql injections, html...)
# Cookies, Headers ? 

# When looking for IDORs and have 401/403 errors, some bypasses :
- 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"":""*""}

# SQL injections were very common. BOLA (IDOR) is the new epidemic of API security.

# Testing for IDOR/BOLA?
# Even if the ID is GUID/non-numeric value, always try to send a numeric value
# (for example: ""/?user_id=111"" instead of ""user_id=inon@traceable.ai"")
# Sometimes there's support for both."

# IDOR
# IDs in the HTTP bodies / headers tend to be more vulnerable than IDs in URLs.

# Never assume there’s only one way to authenticate to an API!
# `/api/mobile/login` | `/api/v3/login` | `/api/magic_link`;

# Web Servers(IIS, Apache) treat static resources differently when it comes to authorization.
# There's a good chance you can access static resources of other users.

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

# Testing Ruby on Rails App & found a param that contains a URL?
# Developers sometimes use ""Kernel#open"" to access URLs == Game Over.
# Just send a pipe as the first character and then a shell command (Shell Injection by design)"

# Pentest for .NET apps? saw a param containing file path/name?
# Developers sometimes use "Path.Combine(path_1,path_2)" to build full path.
# Path.Combine has weird behavior: if param#2 is absolute path, then param#1 is ignored.
# - Leverage it to control the path -

# "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"".

# 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

# Older versions of APIs tend to be more vulnerable and they lack security protection.
# Saw a call to 'api/v3/login'? Check if 'api/v1/login' exists as well.

# Scan the .js files for strings that look like URLs(Some of them are API endpoints)

# If the API has mobile clients, download old versions of the APK file 
# to explore old / legacy functionality and discover new API endpoints.

# Pentest for REST API? Give it a chance, check if the API supports also SOAP.
# Change the content-type to "application/xml", add simple XML in the request body
# and see how the API handles it.

# Found a "limit" / "page"? (e.g: /api/news?limit=100) It might be vulnerable to Layer 7 DoS.
# Try to send a long value (e.g: limit=999999999) and see what happens :)

# "The API uses Authorization header? Forget about CSRF!
# If the authentication mechanism doesn't involve cookies, the API is protected against CSRF by design."

# Burp is really usefull
# Uses the tree view to see each accessed endpoints