HackBlue

Tools · Workbench

Web testing tools

Lessons on reading the requests an application makes, and on sorting scanner alerts into false leads, minor issues, and findings.

  • 23 lessons
  • 6 h of reading
  • 3 topics
Start with lesson 1All workbenches

A testing proxy sits between a browser and an application and shows the request the page had hidden. A scanner adds its own checks and a list of alerts. The lessons linked below are about reading one request, and about deciding which alerts are worth a fix.

Point a proxy or a scanner at an application you own, or at a training range that expects it. Use a lab browser profile for any testing certificate. An automated scan can lock accounts and change data, so it belongs in the written scope.

Burp

11 lessons

  1. 01Burp’s proxy, placed on a lab browserBurp’s proxy is a local listener between a browser you reserve for the lab and an application you are allowed to test. This lesson puts that listener in front of Harbor Ledger and keeps the certificate off your daily profile.16 min
  2. 02Intercept rules that pause only the labIntercept holds a request on screen before the lab app sees it. The useful setting is a rule that pauses Harbor Ledger posts and lets everything else go through, so you can read a message and forward it unchanged.15 min
  3. 03Reading Burp’s HTTP historyHTTP history is the time-ordered record of what the lab browser asked for. The skill is to filter it down to Harbor Ledger’s API and to read one row completely: method, path, account, status, and the field that answers your question.16 min
  4. 04Scope that includes Harbor Ledger and nothing elseTarget scope is the list Burp uses to decide which hosts count. For this lab the list is one origin, http://127.0.0.1:3000. Everything the browser does besides that stays out, even when it shows up in history.15 min
  5. 05Repeater: read one authorized request, then send it againRepeater holds a single request you were already allowed to make, so you can read it slowly and send that same request again. On Harbor Ledger that means replaying Avery’s own invoice call and comparing the two responses, without wandering into other identifiers.17 min
  6. 06Comparer: what changed between two lab responsesComparer lines up two responses you already collected and shows the words that differ. On Harbor Ledger the useful pair is Avery’s two own invoices, so the diff teaches the tool on data the account was allowed to read.14 min
  7. 07Decoder, and the encodings it does not breakDecoder turns URL encoding and ordinary base64 back into text you can read. It does not open TLS, it does not reverse a password hash, and a readable label is not a session you are allowed to edit.15 min
  8. 08Logger: capture the lab, and filter the viewLogger records traffic from Burp’s tools in one table, which is how a Repeater send and the original browser call end up side by side. The capture rule and the view filter keep that table on Harbor Ledger.15 min
  9. 09Project files hold the lab sessionA Burp project on disk is a full copy of the history, including Avery’s session cookie. A temporary project dies when you close the window. Either choice is safe only if you know which one you opened and where the file would go.14 min
  10. 10Walkthrough: map Harbor Ledger from a cold startThis is the full pass: temporary project, listener, scope, intercept off, one clerk’s click-through, then history, the site map, a single Repeater replay, and a note someone else can check. Nothing in the pass leaves 127.0.0.1:3000.22 min
  11. 11The inspector and a note someone else can checkThe inspector breaks one message into method, path, headers, cookies, and body fields so you can read it without losing your place in the raw text. The note you keep is a short form filled from that breakdown, not a paste of the whole message.14 min

ZAP

6 lessons

  1. 01A ZAP baseline against Harbor LedgerA baseline scan spiders the lab and runs passive checks on what it fetched. It is a coverage pass against http://127.0.0.1:3000, followed by a report you read. It is not a verdict, and it is not the active scanner.16 min
  2. 02Reading a ZAP alert as a claimAn alert names a rule, a URL, a risk, a confidence, and an evidence snippet. On Harbor Ledger you read those fields as a claim about one response, then you open that response and see whether the claim is true.16 min
  3. 03ZAP’s Sites tree and History tableThe Sites tree is ZAP’s map of hosts and paths. History is the time-ordered table of every message the proxy or the spider recorded. You use the tree to see the shape of Harbor Ledger and the table to read one exchange.15 min
  4. 04The ZAP HUD on the lab browserThe HUD lays a small ZAP panel over the lab page in the browser, so alert counts and a few tools sit next to Harbor Ledger. The desktop History table remains the record. The overlay is a convenience, and only on the lab origin.14 min
  5. 05A ZAP context that is only Harbor LedgerA context is ZAP’s name for the set of URLs that belong to one application. The Harbor Ledger context includes http://127.0.0.1:3000 and can exclude static files and the logout path so a spider does not wander or sign you out.15 min
  6. 06What not to trust in a scanner alertA ZAP alert is a rule’s claim about a response. Trust the raw History entry more than the risk label, and trust a header you can see more than a plugin name. You confirm or you reject. You do not “follow the alert” into a deeper attack.17 min

DevTools

6 lessons

  1. 01The Network panel on a page you are debuggingThe Network panel lists every request the lab page made, in order, with status and type. On Harbor Ledger it is how you see that the invoice screen is a document plus a JSON call, and how you notice a second call you did not expect.15 min
  2. 02Preserve log, so a navigation does not eat the evidenceBy default the Network list clears when the browser navigates. Harbor Ledger’s Save note button navigates away while a POST is still in flight, and the row vanishes unless Preserve log is on. The canceled POST is the bug.15 min
  3. 03The initiator column: which line sent this requestInitiator names the parser, a redirect, or a script location for each Network row. On the canceled note save it points at app.js, which is how you know the navigation and the POST came from the click handler and not from the browser’s address bar.15 min
  4. 04Request and response panes: headers, body, and previewSelecting a Network row opens the request headers, the request body, the response headers, and the response body. Preview renders JSON. Response shows the bytes. On Harbor Ledger you use that split to check the owner field and to see a POST that never got a response.16 min
  5. 05Application storage: cookies, local storage, and a stale draftThe Application panel (Storage in Firefox) shows what this origin keeps on disk: cookies, local storage, and session storage. Harbor Ledger’s draft note lives in local storage, and a leftover draft from another lab user is a front-end bug you can see without sending a single attack.16 min
  6. 06Walkthrough: why Save note loses the textThis pass uses the Network list, Preserve log, the initiator, the request panes, and local storage on one Harbor Ledger bug. The button navigates away before POST /api/notes finishes, and a stale draft can still be sitting in the browser after the server never stored it.18 min