Skip to content

crAPI-Pentest.md

Latest commit

 

History

History
executable file
·
341 lines (235 loc) · 14.4 KB

crAPI-Pentest.md

File metadata and controls

executable file
·
341 lines (235 loc) · 14.4 KB
Raw

crAPI Hands-On Pentest Notes

Personal practice notes for testing crAPI (Completely Ridiculous API) — a deliberately vulnerable app used to learn the OWASP API Security Top 10.

Reverse Engineering APIs

Two methods for discovering and documenting all of crAPI's endpoints by capturing real traffic, instead of guessing at routes.

Method 1 — Using Postman

  1. Create a new Workspace → create a Collection.
  2. Bottom-right corner → Tools → Proxy → enable Proxy (pick a free port, e.g. 5555) → click Start Capture.
  3. On the machine running crAPI, open Firefox with the FoxyProxy extension → point it at the same port (8082 or 5555 — double-check which one is actually active/listening).
  4. With the proxy capturing, exercise every feature of the app: sign up, sign in, place an order, request a refund, etc. — hit as many flows/features as possible so every endpoint gets captured.
  5. Once done, go back to Postman → select all captured requests in the workspace/collection view → Add all to collection.
  6. Create a folder named 127.0.0.1 (or whatever the host is).
  7. Sort the captured links by API namespace into subfolders, e.g.: community, identity, workshop.
  8. Inside identity, create an additional subfolder for v2 API routes, and move the relevant v2 endpoints into it.

Result: a fully organized Postman collection mirroring crAPI's real API surface, sorted by service/version.

Method 2 — Using mitmweb + mitmproxy2swagger

  1. Set up FoxyProxy to listen on the same port as mitmweb (same setup as Method 1).
  2. Exercise every endpoint/feature in the app again (sign up, sign in, orders, refunds, video upload, etc.) while mitmweb captures traffic.
  3. Once done: in mitmweb, go to File → Save as → save the flows file.
  4. Stop the interception.
  5. Go to the Downloads folder — the flows file should be there.
  6. Use Swagger (via mitmproxy2swagger) to turn the captured flows into an OpenAPI spec.

Step-by-step: generating the Swagger spec

Step 1 — Activate your Python environment

Open a terminal, go to your Downloads folder, and activate the virtual environment you created earlier:

cd ~/Downloads
source ~/mitm_env/bin/activate

Step 2 — First run (build the initial route list)

Generate a first-pass list of API routes from the flows file (no sudo, no extra flags):

mitmproxy2swagger -i flows -o spec.yml -p http://127.0.0.1:8888 -f flow

Step 3 — Sed command (unlock all endpoints)

The initial spec marks many routes with ignore: tags. Strip all of them in one shot so the tool will process every route:

sed -i 's/ignore://g' spec.yml

Step 4 — Second run (build the full schema with real data)

Re-run the same command to pull the actual data (HTTP method, headers, body) for the now-unlocked routes back from the flows file, producing a complete, working Swagger file:

mitmproxy2swagger -i flows -o spec.yml -p http://127.0.0.1:8888 -f flow

Step 5 — Import and clean up in Swagger Editor

  1. Go to editor.swagger.io.
  2. Import File → load spec.yml.
  3. All endpoints should now be visible as a well-documented API spec.
  4. Use the Edit option on the left panel to rename the title to crAPI.
  5. Download the finished spec.

Step 6 — Bring it into Postman

Import the downloaded Swagger/OpenAPI document into the same Postman collection created in Method 1 — it now sits alongside the manually sorted folders from the first method, giving you two cross-checked views of the same API surface.

01 — Scanning APIs for Vulnerabilities

1. Nikto

nikto -h http://127.0.0.1:8888

2. OWASP ZAP

2.1 — Automated Scan Run ZAP's automated scanner against:

http://127.0.0.1:8888

2.2 — Manual Explore Also walk through the app manually inside ZAP (same coverage as the automated crawl) to catch anything the automated spider misses.

02 — Classic Authentication Attacks

  1. Stop mitmweb.
  2. In Postman, go to proxy settings and set the port to 8080.
  3. Open Burp Suite → Proxy settings → set Burp's listener to the same port (8080) so Postman's traffic routes through Burp.
  4. Using the Postman collection/documentation built earlier, send a request through Postman (start with the login request) and capture it in Burp.
  5. Send the captured login request to Repeater.
  6. Resend it a few times to check for rate limiting or watch for changes in the response code.
  7. If nothing changes (no rate limiting) → move to brute force.
  8. Send the request to Repeater, then brute-force it with wfuzz:
wfuzz -d '{"email":"test1@email.com","password":"FUZZ"}' \
  -H 'Content-Type: application/json' \
  -z file,rockyou.txt \
  -u http://127.0.0.1:8888/identity/api/auth/login

03 — BOLA (Broken Object Level Authorization)

Concept: User A can view information belonging to User B by manipulating an object reference. (This overlaps with IDOR — same root cause, viewed through the OWASP API Top 10 naming.)

Test: Grab a user ID from a community post's response, then send that ID in a different request to the identity API and see if it returns that user's private data.

04 — BFLA (Broken Function Level Authorization)

Test 1: In the collection's order section, change the order ID (e.g. from 10) to a different value and see if you can act on an order that isn't yours.

Test 2: On an uploaded video's rename endpoint, change the method from PUT to DELETE and try to delete the video — while authenticated as a regular user, not admin — to see if the privilege check is missing at the function level.

05 — Advanced Vulnerability Exploitation

Postman Runner (Collection Runner): Use the Collection Runner to check API behavior across versions — there's an option to run against a single request or the entire collection at once, which is a fast way to sweep every endpoint for a given check.

Steps:

  1. After identifying v3 endpoints via mitmproxy2swagger, go to the forgot password flow.
  2. Target the OTP check endpoint and brute-force the OTP using wfuzz:
wfuzz -d '{"email":"test@test.com", "otp":"FUZZ", "password":"NewPassword@123"}' \
  -H 'Content-Type: application/json' \
  -z file,/usr/share/seclists/Fuzzing/4-digits-0000-9999.txt \
  -u http://127.0.0.1:8888/identity/api/auth/v2/check-otp \
  --hc 500

--hc 500 hides responses with HTTP 500 status, so only valid/interesting responses (successful OTP guesses) remain visible in the output.

1. IDOR (Insecure Direct Object Reference)

Concept: In a request, find the identifier being sent (ID, location, community, etc.) and change its value to see if you can access another user's data.

Test for:

  • Identifier
  • Location
  • Community

If changing the value returns another user's data → IDOR confirmed.

2. Broken Authentication

Concept: Look for ways to move into another user's authenticated session/behavior.

Focus areas: Behavior + Operation

What to check:

  • Cookie leakage → can it be used to hijack another user's session token?
  • Password reset flow
  • OTP flow (brute force / bypass)
    • Check OTP length — is it still 4 digits, or has it moved to 6 digits?
  • Rate limiting on auth endpoints → 429 = Too Many Requests / Rate Limit hit
  • API versioning — check v2 / v3 endpoints (older versions often still work = Improper Assets Management)

3. Excessive Data Exposure

Concept: The API returns more data than the client actually needs. Developers often push all fields to the client side (JS) to make front-end work easier — pick whatever you need from the response.

Example 1: Community post → inspect the post author's full detail object in Burp Suite (often contains extra PII not shown in the UI).

Example 2: Video upload request → check the request/response for exposed internal IDs and parameters, e.g.:

"conversion_params": "-v ..."

This parameter can potentially be used to inject/run commands (see Mass Assignment below) — related to the H.264 codec vulnerability.

Note — Serialization vs Deserialization vulnerability (related concept): An attacker crafts a malicious object, serializes it, and sends it to the application. When the application trusts and deserializes it, the attacker's malicious code executes on the backend server.

Mitigations:

  1. Avoid native serialization formats (e.g., Java Serializable, Python pickle) — prefer safe text formats like JSON or XML, which carry far less risk of direct code execution.
  2. If serialized data must be used, attach an HMAC / cryptographic signature to detect tampering.

4. Rate Limiting & Lack of Resources

Test: Send a mechanic report request and flip repeat_request_if_failed to true, with a high repeat count:

{
  "mechanic_code": "TRAC_JME",
  "problem_details": "rate limit test",
  "vin": "T4AN07C7KXGXA0SUA",
  "mechanic_api": "http://127.0.0.1:8888/workshop/api/mechanic/receive_report",
  "repeat_request_if_failed": true,
  "number_of_repeats": 1000
}

If the server accepts and repeats 1000 requests with no throttling → lack of resources & rate limiting confirmed.

5. Broken Function Level Authorization (Vertical IDOR)

Concept: A request meant for role: user (e.g., deleting an item) should be rejected — try changing the role to role: admin and resend.

Also test: Renaming an uploaded video — change the name field and see if the server allows an action beyond your privilege level.

Method enumeration trick: Send an OPTIONS request to the endpoint. Check the Allow: response header — it lists which HTTP methods are permitted (may reveal methods you shouldn't have access to, like PUT/DELETE).

6. Mass Assignment

Case 1 — Negative value injection: When ordering an item, check the request body for pricing/rate fields (dam/rate) and try setting a negative value.

Think of an object like a "seat" or a "student" — each has properties (height, class, picture, etc.). Any property in that object could potentially be manipulated if the server doesn't restrict which fields are writable.

Case 2 — Status/quantity override via PUT: On a "return item" request, check if the response object's fields can be freely updated via PUT:

{
  "status": "returned",
  "quantity": "10"
}

Case 3 — Command injection via conversion params: On the video "repeat conversion" request, modify conversion_params:

{
  "videoName": "ggg.mp4",
  "conversion_params": "-v codec h264 && whoami"
}

If this executes with admin privilege, that's mass assignment. Confirm by testing:

"-v cache h254 && whoami"

If the response returns 200 OK → Mass Assignment confirmed.

7. Injection — SQL / NoSQL Injection

Concept: Test injection wherever user input is validated against the database.

Step 1 — Basic SQLi payload: Didn't work → pivot to NoSQL.

Step 2 — NoSQL injection (works):

{"coupon_code": {"$ne": null}}

Step 3 — SQL injection (works):

{"coupon_code": "'; select version();--", "amount": 75}

8. Broken Access Control / SSRF

Test setup: Shop → Past Orders → open any previous order → send to Burp Repeater → remove the Authorization header entirely → resend.

If the response still returns order information despite no auth header → vulnerability confirmed.

IDOR vs SSRF/Broken Access Control — key distinction:

  • IDOR: Authorization is present (you're logged in, you have a valid header/cookie), but you can still view another user's data by swapping an identifier.
  • SSRF / Broken Access Control: Authorization header is missing entirely, and you can still see another user's report. Neither check (authentication nor ownership) is enforced — so this is both an SSRF-style issue and a broken access control issue at once.

SSRF test: In the mechanic API, replace the report URL parameter with google.com. If the server-side makes the outbound request to Google on your behalf → SSRF confirmed.

9. Hacking JSON Web Tokens (JWT)

Attack 1 — Algorithm Confusion Attack (RS256 → HS256)

  1. Get the JWKS / public key values e and n (via content discovery — fuzzing / directory brute-forcing).
  2. In Burp's JWT Editor extension → click New RSA Key → paste in the e and n values.
  3. Click PEM to generate the key → copy the PEM key.
  4. Go to Burp's Decoder tab → paste the PEM key → encode as Base64.
  5. Back in JWT Editor → click New Symmetric Key → click Generate.
  6. Replace the generated k value with the Base64 string copied in step 4 → click OK (this creates your new signing key).
  7. Go to the Proxy tab → send the target dashboard request to Repeater.
  8. In Repeater, open the JSON Web Token tab → view token details.
  9. Change the user field to admin.
  10. Since the signature must also change, go to Sign → change algorithm to HS256 (a symmetric algorithm — we're deliberately converting from asymmetric to symmetric).
  11. Click Update "alg" parameter → OK → Send.

Result: no issue found in this test run — this is the classic algorithm confusion attack technique regardless.

Attack 2 — "None" Algorithm Attack

In the same Repeater JWT tab:

  • Set "alg": "none"
  • Leave the signature field blank
  • Send and observe if the server still accepts the token.

10. Using Postman for API Pentesting

Scenario 1: Client gives you a website connected to an API and asks you to test the API — this is exactly the kind of testing done against crAPI at 127.0.0.1:8888.

Scenario 2: Client only gives you an API endpoint, e.g. http://jubai.com/api/user.

Why Postman:

  • By default, a browser only sends GET requests.
  • Most API testing requires POST (and other methods) — you can do this from a browser, but you'd need to write full HTML/JS to fire a POST request, which gets complex fast.
  • Postman is essentially a browser with one key extra feature: it lets you explicitly choose which HTTP method to send a request with (GET, POST, PUT, DELETE, OPTIONS, etc.).

Summary: Postman is a browser that gives you the additional ability to select the HTTP method for a request.