API Test Case
Get Two credentials for user and admin(if available
User: user 1 ----> victim – [Link]@[Link] - Anil@1298
user 2 ----> Attacker - ramu@[Link] - Ramu@1298
Admin: admin 1 ----> victim
admin 2 ----> Attacker
Test case 1: BOLA (Broken Object Level Authorization) by changing auth
token ===> IDOR (Insecure Direct Object
Reference)
Login to victim credentials and intercept the request and check
whether we can login to attacker with the token by replacing victim path
with Attacker
Get attacker auth token
Add it in dashboard
Select endpoint in the inventory (PATCH reviews)
Review the payload once.
Look at the original review (this is the original review)
Run test by selecting one BOLA case - BOLA by changing auth token
Look at the test results - API is vulnerable
Test result and attack attempt
Look at the edited review on the dashboard (some review edited for the
first time)
[Link].mp4
[Link].mp4
Test 2 : Broken Function Level Authorization by changing HTTP Method
Open the API collection that you want to test for vulnerabilities.
Click on Run test button.
Select only Broken Function level authorization by changing HTTP
method test.
Count to 10-Mississippi for Test results.
Analyze the High severity issues.
Here, we selected the /api/cards endpoint that fetches all the credit
card info from all users.
[Link].mp4
[Link].mp4
Test 3 : Broken user authentication by removing auth token
Set attacker token
Observe api (Feedbacks endpoint in this case)
Select this endpoint
Click on Run test with just Broken Auth
Wait for test result
Check original attempt has auth token
Test attempt doesn't have token, yet it succeeded - Broken user
authentication vulnerability found. 🔑
[Link]
[Link]
Test 4 : Swagger file detection - Security misconfiguration
Click on run and select swagger file detection test
Go to testing and wait for a minute for test results
Click on the failed test - Assets found on page
Click on the Attempt tab to see the test API call
The response contains HTML page with swagger details
Verify it by actually entering the URL
🐞 Detected unprotected swagger file!
[Link].mp4
[Link].mp4
Test 5 : JWT None algo attack
Look at the original data - last name is "johnson"
Select the endpoint you want to test for JWT None attack
Click on Run test and select JWT None algo attack
Look at the test results - 1 HIGH severity issue found
Akto made 4 attempts - 1 succeeded with 200 OK
Refresh website, notice lastname changed from "johnson" to "victim"
Look at the attack again, check the token on [Link]
Observe algo=none
🐞 JWT None algo vulnerability found
[Link].mp4
[Link].mp4
Test 6 : JWT failed to verify signature test
Select a POST order endpoint
Select the Broken Authentication test - JWT failed to verify signature
Go to test results. Observe that there is a high vulnerability issue
Check the Original tab - the original token signature starts with "HQq0"
Check Attempt tab - gives 200 OK response with signature starting with
"aQq0" - this is invalid signature, yet server accepted
[Link].1.mp4
[Link].1.mp4
Test 7 : Broken Object Level Authorization by Parameter Pollution
Select BOLA by parameter pollution
Run test.
Check results
The original request has 3 params.
Attempt request has 6 params - all occurring twice with a diff "BasketId"
value.
This results in a success response
The victim's cart has a new product added now!
🐞 Vulnerable API
[Link].mp4
[Link].mp4
Test 8 : Broken Object Level Authorization in old API versions
Select the list of endpoints
Select Old version API tests.
Go to the test results section
Check details for the vulnerability
Notice that original endpoint uses v2 - /api/v2/users
Navigate to Attempt tab
Notice that /api/v1/users also returns 200 OK with the flag
🐞 BOLA in old api versions
[Link].mp4
[Link].mp4
Test 9 : Security misconfiguration - django-exposed-debug-page
Select the Django-exposed-debug-page test and run it
Wait for the result
Check the Attempt tab and look for debug details in the response
Check details for the vulnerability
Observe we open the debug page - with details of modules, and inner
workings of Django server code
🐞 django-exposed-debug-page
[Link].mp4
[Link].mp4
Test 10 : Security misconfiguration - Open redirects
Select the API Collection you want to test
Select Open-redirect test under Security Misconfiguration and click on
run test
Navigate to testing. Notice, Akto has found all the APIs which have open
redirects
Click on the vulnerability to see details.
Notice that the original request redirects to GitHub
Navigate to Attempt tab. Notice Akto tries a test to redirect to evil. com
See the attempt succeeds! Server returns 302 with location evil. com.
🐞 API is vulnerable!
[Link].1.mp4
[Link].1.mp4
Test 11 : Application DOS due to pagination misconfiguration
Select the API collection you want to test
Select "Pagination Misconfiguration" test under "Rate limiting" category.
Run the test and navigate to testing tab.
Click on the test result. Notice this is possible DoS.
In the original request, API asks for 10 results & the response contains
10 objects
In the attack request, API asks for 100 results. Server accepts this
request & sends 100 objects in return
🐞 API is vulnerable!
[Link].mp4
[Link].mp4
Test 12 : API security misconfiguration - exposed metrics endpoint
Select endpoints you want to test for security misconfiguration
Select the misconfiguration test - Prometheus metrics.
Go to test results, wait for a few seconds.
Open the test result "configs" which is a vulnerable result.
Check the Attempt payload and its response - Notice all metrics of
Juiceshop exposed.
🐞 API is vulnerable!
[Link].-.[Link].1.mp4
[Link].-.[Link].1.mp4
Test 13 : SSRF - AWS sensitive data exposed.
Select your API collection.
Run SSRF test on your collection.
Akto runs this test only on those endpoints which take in a URL
parameter.
Navigate to test results.
Note the original response has no sensitive keywords such as instance-
type etc.
In the attempt, notice that the response has sensitive data such as
instance-type, local-hostname, local-ipv4.
🐞 API is vulnerable!