Exploiting Injection, Auth, and API Vulnerabilities

What You'll Build

In this phase you will use your attack-surface map to find and confirm real vulnerabilities across the three areas the course covered: injection, authentication and session flaws, and API authorization. For each confirmed flaw you will capture evidence and reproduction steps, building the findings that will populate your report. This is where the course's knowledge becomes demonstrated exploitation.

Analogy🏏Cricket

💪 Think of it like fitness: Assessment day is when the training gets tested for real, you take the map of your programme and put each targeted lift under load to see which strengths hold and which weaknesses are genuine, recording every number. Just as the measured test turns a plan into proven results, using your attack-surface map to probe injection, authentication, and API authorization, and confirming each real flaw with captured evidence, turns recon into demonstrated findings. This reveals where knowledge becomes proof: you deliberately load each mapped weakness and record exactly what gives way.

The aim is disciplined, evidence-driven testing, not spray-and-pray. Guided by your test plan, you will probe each surface area for its likely flaws, confirm what is real by safely triggering it, and document each finding rigorously. By the end you will have a set of confirmed, evidenced vulnerabilities ready to be scored and remediated.

Analogy🏏Cricket

🏏 Think of it like cricket: A disciplined bowling attack does not spray deliveries everywhere and hope; guided by the scouting report, it targets each batter's flagged weakness, confirms the ball is doing what was planned, and records every dismissal for the analysts. Just as that planned, evidence-backed attack turns a dossier into wickets rather than wasted overs, working your test plan area by area, confirming each real flaw by safely triggering it, and documenting it rigorously turns recon into evidenced findings. This reveals the method: targeted, confirmed, and recorded beats spray-and-pray every time.

Prerequisites

The consolidated attack-surface map and test plan from Lesson 32, plus the running capstone app and your HTTP client.
Completion of the Modules 2–4 readings on injection, authentication, and API security, whose techniques you will now apply.
Your engagement log open, ready to capture each request, response, and evidence screenshot for every confirmed finding.
An understanding that all exploitation here targets only your local capstone app, and that these techniques are unauthorised elsewhere.

Setup & Project Structure

Work through your test plan area by area, keeping the engagement log open to record evidence as you confirm each flaw. For every finding you will capture the exact request that triggers it, the response that proves it, reproduction steps, and the affected endpoint. Organise your notes so each confirmed vulnerability is a self-contained record ready to drop into the report.

Analogy🏏Cricket

📷 Think of it like photography: A professional does not trust memory on a shoot; every frame is captured with its settings, the aperture, the shutter, the exact scene, so the shot can be reproduced and proven later. Just as that per-frame metadata makes each image a self-contained, repeatable record, working your test plan area by area and capturing the exact request, the response that proves impact, the reproduction steps, and the affected endpoint makes each finding a self-contained record. This reveals the discipline: evidence recorded at the moment of capture is what makes a finding stand up in the report.

bash

# Work the test plan from Lesson 32, recording evidence per finding.
# For each confirmed flaw, capture in engagement_log.csv:
#   - endpoint + exact request (method, path, headers, body)
#   - response proving impact (status, leaked data, reflected payload, delay)
#   - reproduction steps  - screenshot/evidence id  - vuln class
# All requests target ONLY http://localhost:3000 (your machine).

Step 1 — Foundation: Confirm Injection Flaws

Start with the injection surface from your map. Test parameters for SQL injection using the techniques from Module 2, watching for visible output, behavioural differences, or timing, and test reflected inputs for XSS by checking whether a payload is returned unencoded. Confirm each real flaw with a minimal, safe proof and record the triggering request and the evidence of impact.

Analogy🏏Cricket

♟️ Think of it like chess: A strong player opens by testing the line the analysis flagged as your weakest, playing the probing move and watching your reply before committing to the attack. Just as that opening probe confirms the scouted weakness before the pressure builds, testing mapped parameters for SQL injection, watching for errors, altered results, or timing, and checking whether input reflects unencoded for XSS confirms the flaws your recon predicted. This reveals the disciplined start: test the highest-likelihood weaknesses first, and prove each with a minimal, clean move.

bash

# Injection tests against mapped parameters (local target only)
# SQLi confirmation (tautology / behavioural difference):
curl -s "http://localhost:3000/search?q=test'--"        # error or altered result?
curl -s "http://localhost:3000/search?q=x' OR '1'='1"    # returns extra rows?

# Reflected XSS confirmation (is the payload returned unencoded?):
curl -s "http://localhost:3000/search?q=<b>xss</b>" | grep -o '<b>xss</b>'
# If the raw tag comes back, it's reflected. Record request + evidence.

Step 2 — Core Logic: Break Authentication and Sessions

Next, target the authentication and session surface. If the app issues JWTs, test for the none-algorithm bypass and weak signing from Module 3. Check session handling: is the identifier regenerated at login, are cookies protected, is the login endpoint rate limited? Probe the password-reset and other auth flows for logic flaws. Confirm and evidence each real weakness as a distinct finding.

Analogy🏏Cricket

⚽ Think of it like sports: A striker who has exposed one gap in the defence immediately probes another, testing the offside line, then the far post, then the keeper's near side, widening the advantage across the whole back line. Just as attacking several facets in turn builds sustained pressure, testing the JWT for a none-algorithm bypass, checking whether the session id regenerates at login, whether cookies are protected, whether login is rate limited, and probing the reset flow builds a fuller picture of the auth surface. This reveals the progression: move methodically across authentication, confirming each weakness in turn.

bash

# Auth/session tests (local target only)
# JWT 'none' bypass (from Module 3): forge alg:none with elevated claims
HEADER=$(printf '{"alg":"none","typ":"JWT"}' | base64 | tr -d '=' | tr '/+' '_-')
PAYLOAD=$(printf '{"user":"demo","role":"admin"}' | base64 | tr -d '=' | tr '/+' '_-')
curl -s http://localhost:3000/admin/config -H "Authorization: Bearer $HEADER.$PAYLOAD."

# Session checks: is 'sid' regenerated at login? HttpOnly/Secure set?
# Rate limit: does the 6th rapid login attempt still get 200 instead of 429?

Step 3 — Integration & Enhancement: Exploit API Authorization

Now test the API surface for the authorization flaws from Module 4. For object endpoints, attempt to access another user's object by changing the identifier, confirming broken object level authorization. For privileged routes, attempt to invoke them as a normal user, confirming broken function level authorization. Check whether responses leak sensitive fields. Each confirmed flaw becomes an evidenced finding with its request and impact.

Analogy🏏Cricket

💰 Think of it like finance: An auditor tests controls by trying to move money the way an insider might, requesting another client's account, then attempting a transaction only a manager should authorise, watching for anything that clears when it should be blocked. Just as those targeted control tests expose broken permissions, changing an identifier to reach another user's object exposes broken object level authorization, invoking a privileged route as a normal user exposes broken function level authorization, and inspecting responses reveals leaked fields. This reveals the API mindset: match each test to the authorization control it is meant to break.

bash

# API authorization tests (local target only)
# BOLA: read another user's object by changing the id
curl -s http://localhost:3000/api/orders/2 -H "Authorization: Bearer <user1-jwt>"
# If it returns user 2's order -> broken object level authorization.

# BFLA: invoke a privileged route as a normal user
curl -s -X POST http://localhost:3000/api/admin/refund \
  -H "Authorization: Bearer <normal-user-jwt>" -d '{"orderId":2}'
# If it succeeds -> broken function level authorization.
# Also inspect responses for leaked fields (excessive data exposure).

Step 4 — Testing & Verification: Compile Confirmed Findings

Finally, compile your confirmed findings into a structured list ready for scoring and remediation. For each, record the vulnerability class, the affected endpoint, the exact reproduction steps, the evidence of impact, and a preliminary severity impression. Verify every finding is genuinely reproducible by running its steps once more from a clean state. This evidenced list is the raw material of your report.

Analogy🏏Cricket

🎬 Think of it like movies: Before the edit, an editor logs every usable take, tagging the scene, the timecode, and a note on quality, then re-watches each clip to be sure it actually holds up. Just as that verified shot list is the raw material the final cut is assembled from, compiling each confirmed flaw with its vulnerability class, affected endpoint, reproduction steps, evidence, and a preliminary severity, then re-running its steps from a clean state, is the raw material your report is assembled from. This reveals why verification matters: a finding you cannot reproduce on demand does not belong in the final cut.

markdown

# Confirmed findings list (feeds scoring in Lesson 35)
#
# F1  SQL injection      /search?q=      evidence: scr_11  impact: data dump
# F2  Reflected XSS       /search?q=      evidence: scr_12  impact: script exec
# F3  JWT none bypass     /admin/config   evidence: scr_14  impact: admin access
# F4  BOLA                /api/orders/:id evidence: scr_16  impact: read others' orders
# F5  BFLA                /api/admin/refund evidence: scr_18 impact: privileged action
# F6  No login rate limit /login          evidence: scr_19  impact: brute force
#
# Re-run each finding's steps once from a clean state to confirm reproducibility.

Warning: Every exploitation technique in this phase is for your local capstone application only. Sending injection, XSS, forged-token, or authorization-bypass requests to any system you do not own or lack written permission to test is unauthorised access and a crime. Keep all requests on localhost, and never rehearse these techniques against live or third-party targets.

Extension Challenge: Extend your testing three ways. Chain two findings into a higher-impact attack, for example using an XSS to steal a session and then exercising a BOLA with it, and document the chain. Attempt a blind or time-based SQLi variant if the visible one is patched, proving the technique from Lesson 7. Finally, quantify a BOLA's reach by enumerating how many objects you could access, strengthening the finding's severity evidence.

Exploitation is guided by the recon test plan: probe each mapped surface area for its likely flaws rather than testing at random.
Injection findings are confirmed by observing visible output, behavioural differences, or timing for SQLi, and unencoded reflection for XSS.
Authentication findings include JWT none/weak-signing bypasses, missing session regeneration or cookie flags, and absent login rate limiting.
API findings confirm broken object level authorization by changing identifiers and broken function level authorization by invoking privileged routes as a normal user.
Every confirmed flaw is recorded as a self-contained finding with the triggering request, response evidence, reproduction steps, and affected endpoint.
Findings are re-run from a clean state to verify reproducibility, producing the evidenced list that becomes the raw material of the report.