This is curated post from Inon Shkedy Tweets 30 Days of API Security
src: https://x.com/InonShkedy/status/1663976241920131087
About Inon Shkedy
- API Security Project Leader at OWASP
- Head of Security Research at Traceable.ai
- Medium: https://inonst.medium.com
- Twitter: https://twitter.com/InonShkedy
API Tip 01
How to use Burp Suite features with APIs:
- Stability: Unlike Fiddler and other web proxies, Burp never crashes.
- “HTTP History” - view all API Calls since you started the pentest. Some APIs become interesting only after you understand the app.
- “Tree view” - understand the API structure & business model behind it
- “Intruder” - automate BOLA exploits easily
- “Repeater” - save interesting API calls to demonstrate to customer later
- After you spent a few hours testing API, You found an AP, but don’t know how to use it? Use “search” -> look for EP name only in responses. Find JS & HTML that use the EP.
API Tip 02
- Testing a GraphQL API that returns sensitive data?
- If the query contains a “filter” param, try to send an empty value {“filter”:""}
- API might return data of other users.
API Tip 03
- “detailed errors” worst case scenario& why you should always look for them:
- During pentest (e-commerce), had to find a critical vulnerability as fast as possible.
- I didn’t find much, so I started sending weird inputs that would trigger errors.
- Found a feature to renew my VIP membership
- I changed one JSON property - {“yearStart:“2023”} –> {“yearStart”:“20rr23”} to break syntax
- API returned a super detailed error (2KB)
- Apparently, behind the scenes, EP used a legacy internal API
- External API passed the problematic value to the internal API
- Problematic value caused a parsing error in the internal API
- Internal API generated a super long error, including full details of the internal API request
- Error contained URL of internal API & Authorization header (basic Auth) of internal call
- I accessed internal API from an American IP address (VPN)
- Used the user:pass from AuthZ header (base64)
- Gain FULL access to the management console 😈 From the management console I could edit all store item, and gained full access to the customer base
API Tip 04
- Many modern B2B apps allow you to change the ownership of objects.
- These flows tend to be vulnerable to IDOR/BOLA.
Example:
- If a task management platform allows you to assign a task to a different team member flow, try to:
- Assign yourself a task that doesn’t belong to your team
- Assign your task to a user who’s outside your team
API Tip 05
How to find credentials:
- GitHub exposed secrets
- Analyze clients’ JS; analyze old JS
- Look for JWT tokens, auth tokens
- Analyze mobile clients + old versions
- Run dictionary attacks + google hacking to find additional JS files
- Error traces
API Tip 06
- http://privacy.com - amazing tool.
- Allows you to create anonymous credit cards with spending limits.
Use:
- Test business flows involving payments
- buy products from unsafe websites
API Tip 07
Hunting for BOLA/IDOR? focus:
- IDs in Body/Headers
- Numeric IDs (?id=111)
- Shared by-design objects (/chats/11/message/21)
- EPs that receive multiple IDs
- Old API versions (/v0, /v1, etc)
- Export features (/report_to_pdf?reprit_id=11)
API Tip 08
- Smart bug bounty hunter has to understand the business logic of the API.
- Not all APIs are born equal.
- Business flow X might be sensitive for company X, but not for company Z.
Examples:
- One social network (FB) considers automated comments as spam, while another social network (Twitter) encourages it.
For the former, “captcha bypass” might be an issue, and for the latter not
- Understand the business logic of each API you test
- Look for sensitive business flows
- Read more about “API#6: Unrestricted Access to Sensitive Business Flows”
API Tip 09
IDOR/BOLA tips:
- ID is GUID? send numeric ID anyway; some APIs support both
- Register with an email of an existing user. API might return “user exists” error with ID of the user (map between email & ID)
- Repeat #2 with “forgot password” EP
API Tip 10
- I’ve seen some older websites that use different APIs behind the scenes for different languages.
- Give it a shot and check if the Spanish version of a website is using different APIs behind the scenes - it might expose other vulnerabilities
API Tip 11
How to find SSRF (no tools):
- Use iplogger - simple
- Use http://webhook.site - catches headers
- Susceptible input types:
- File paths
- URL
- Relative paths (any string containing slashed)
API Tip 12
SSRF tip
- Don’t try 127.0.0.1 / metadata services as a first attempt to exploit SSRF - it’s the most obvious payload.
Easy to detect & block.
- Input validation might ignore the payload
- Even worse, WAFs might block you
API Tip 13
- Webhooks + “test webhook” feature = SSRF on steroids.
- “Test webhook” functionality often allows you control headers & HTTP structure.
- Very useful if you want to exploit internal services and management consoles that require special headers
API Tip 14
- “/api/v1/report-v2” == RED FLAG.
- If version is mentioned twice/in non-standard parts of URL, it’s possible that the EP was created as a patch a critical security bug, before the engineering team was ready to come up with a new “v2” api.
If you see these API EPs, try to find the original, unpatched versions :
- Remove “-v2”
- Look for API EPs that are named similarly in:
- JS files & older JS files (using http://archive.org)
- APK & Old APKs (using http://apkpure.com)
API Tip 15
- Always use Burp Suite in background
- After some traffic is generated
- Search history for interesting URLs in response bodies of HTML/JS files.
Examples:
- /_msearch || _search (elasticsearch)
- /graphql
- /admin
- etc..
API Tip 16
Managed to find credentials of someone else? Always try them in different places!
Real world example:
- I tested a mobile app of a large coffee shop chain - used apkpure to find an old version w/o Certificate pinning (save time)
- Interecpted traffic between mobile & API
- HTTP call had “Auth-legacy” header; removed it - nothing happened
- Base64 decoded the header’s value
- found username:password (Basic Auth)
- Used google hacking to expand attack surface
- site:
.com admin - found exposed management console
- used credentials from traffic
- got full access to admin console, including payment info of all users 😈
- got free coffee for one year (in the Bay Area)
API Tip 17
Let’s talk about #bots: Always think which business flows might harm the business if used extensively
Eg: purchase an item | verify coupons | upload picture
<The following flow might cause DoS and/or your user to get blocked>
- Find API EPs related to the flow.
- Generate a legit API call to the EP/s
- Send the API call 100 times
- If all calls return 200 OK - API is vulnerable to “Unrestricted Access to Sensitive Business Flows”
API Tip 18
Software & devops engineers must keep in mind that some EPs are more sensitive than others.
Examples:
- /api/send_verification_code: uses Twilio behind the scenes, company gets charged per use.
- /resize_image: heavy, slow operation & etc…
Malicious users might use these EPs to increase operational cost/cause DoS.
Learn from OWASP API Project how to find and protect these flows: https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/
API Tip 19
IDOR/BOLA hunting tips: Look for encoded JSON objects in cookies.
Example: %7B%22report_id%22%3A111%7D
- they tend be more vulnerable.
Use URL Decoder/Encoder to manipulate the input
API Tip 20
You must understand the business logic of an app in order to find BL vulnerabilities! Methodology:
- Run web proxy in background
- Before sending any malicious calls, spend 30m-3h (depending on scope) exploring the app as a legit user
- Use system as a regular user. Don’t be on auto pilot. Understand why each feature is needed.
- Go back to recorded traffic, look for patterns. Understand:
- API naming
- common params
- how ID handled (guid, int, etc)- AuthN, etc
- Now it’s time to exploit!
API Tip 21
Understand business logic in order to find BL vulnerabilities!
Look for videos/content explaining how to use tested system:
- Youtube
- Pastebin
- PDF files stored under the system domain to find manuals (google hacking)
API Tip 22
Use “bulk import” to bypass input validation.
Example:
- POST
/add_contact?name=<script>alert(21)</script>
- Returns 400? (XSS Blocked 😞 )
Find a feature to upload contacts from file.
- (POST /import_contact_file) - XSS Bypass 😇😇
API Tip 23
- Look on Postman Collections (http://web.postman.co) to find hidden/forgotten APIs of the company you are testing.
- Use collections as documentation to understand better the business logic of the app (might contain comments, value samples, etc)
API Tip 24
BOPLA/“Excessive Data Exposure” exploitation:
- After several hours of pentest, use the Burp Suite search to look for PII in response.
- Also look for business related sensitive data (VIN for vehicle industry, etc)
API Tip 25
Understand AuthN Mechanisms
APIs usually rely on 1 or 2 cookies/headers (aka: Session label) to identify a logged in user.
This value differentiates authenticated from unauthenticated.
How to find:
- Find API call returning user info (e.g, GET /user/profile)
- Use “Proof by contradiction”:
- Duplicate call * number of headers/cookies
- Within each call send only one cookie/header till API returns 200 with your info - that’s the session labels.
Tips:
- Common session labels:
- Session ID Cookies
- Authorization header
- API Key
- Cookies starting with “_” can’t be session labels (99% of cases)
- In some rare cases, session label would be a combination of 2 cookies/headers
API Tip 26
BOLA/IDOR:
- Look for IDs in cookies.
- If you remove cookies (except session ID/AuhtN cookie) from a specific API call, and API returns an error - good chance API fetches something based on cookie value.
- Might be a potential BOLA/IDOR
API Tip 27
Use “export” to find BOPLA/“Excessive Data Exposure”
Example (facebook):
- GET
/api/friends/212
Returns only public info about friend; But - GET
/api/export_friend_list?fields=*
Returns a file with friends’ PII you are not supposed to access
API Tip 28
Save time by comparing response sizes instead of response bodies.
E.g:
- Generate 2 API calls to test for IDOR/BOLA, use 2 different IDs
- 2 API responses have the same size? EP is probably not vulnerable
// Response size are the same - EP isn’t vulnerable to IDOR/BOLA
API Tip 29
- Different API versions expose different vulnerabilities.
- Don’t assume that
api/v1/
and/api/v2
implement the same security mechanisms. - Mechanisms that are often implementad differently across versions:
- Rate Limiting
- AuhtN
- AuthZ
API Tip 30
Feeling stuck but have to find a critical vulnerability?
- Wake up early in the morning.
- Meditate, do some exercise.
- Turn off your phone, disconnect from the world for several hours, drink a coffee.
- Dedicate yourself to the process.
Previous Tips
- https://github.com/Traceableai/31-days-of-pentesting
- https://github.com/inonshk/31-days-of-API-Security-Tips
- 31 Tips — API Security & Pentesting
- https://docs.google.com/spreadsheets/d/1jn3JnWzQFZW41gKo5Fhxwf2ke2w-pvrpCGhBmKhyIBE/edit#gid=0
- https://docs.google.com/spreadsheets/d/12NUeX8RWLrGTP9mss-POjyre8GCx9Z1Co4XMjvKG17A/edit#gid=0