Week 2: HTTP at the Wire Level; CSRF Mechanics

First hardware-contact week. You install Burp Suite, point a browser at the SB6141 administrative interface, capture the request shape, and reproduce the CSRF manually with curl. The lab produces a transcript you will cite in Week 9's disclosure draft.

Theme

A CSRF (Cross-Site Request Forgery) is a textbook example of the session-management failure pattern Stuttard and Pinto describe at depth in The Web Application Hacker's Handbook. The mechanic is the browser's helpfulness: when a user is authenticated to a site, the browser automatically attaches the user's session cookie to every subsequent request to that site, including requests triggered by a different site's HTML form posting cross-origin. An attacker who can cause the user to visit a page they control can post forms to the target site as the user.

The SB6141 case is structurally interesting because the modem's "authentication" is even weaker than session cookies: the device authenticates only by network position (i.e., any device on the local network can reach 192.168.100.1/). This makes the CSRF trivially exploitable: any HTML page the user visits from any browser, on any device on the same network, can issue commands to the modem. The CSRF is the standard browser-cookie-attachment story without even needing the cookie.

The week's lab is the manual reproduction. You set up Burp Suite (the practitioner's HTTP-inspection workhorse), capture the request the SB6141 administrative interface issues for a destructive action (factory reset, reboot), then replay that request with curl from a script you can re-run. The transcript becomes evidence in Week 9 and a building block for Week 4's Python tool.

By the end of Week 2 you can: read an HTTP request at the wire level; use Burp Suite to capture, inspect, and replay HTTP traffic; reproduce a CSRF manually with curl; document the reproduction in a transcript that another researcher could follow.

Schneier weave (~290 words, A Hacker's Mind Ch 3)

Schneier devotes Chapter 3 of A Hacker's Mind to the systemic question of trust boundaries. A trust boundary is the place in a system where the assumptions one component makes about another stop being verifiable. Schneier's examples include democratic institutions (where citizens trust election counts because the counting procedure is observable), financial markets (where traders trust prices because the exchange enforces order rules), and software systems (where one process trusts another because both run within a single security context).

A CSRF is what happens when a software trust boundary is misplaced. The SB6141 administrative interface implicitly trusts the network position of the requester ("if you can reach 192.168.100.1/, you are authorized"). The browser implicitly trusts the user ("if the user navigates here, they want to be here"). The CSRF chains these two trusts into a vulnerability: an attacker who can cause the user's browser to navigate (via a crafted page on a domain the user visits) inherits the user's network position relative to the SB6141.

The structural fix is to align the trust boundary with the security claim. CSRF tokens do this by requiring an unguessable value (the token) to accompany every state-changing request; the token cannot be forged by a cross-origin page because the attacker does not know it. SameSite cookies do this differently by refusing to attach cookies on cross-origin form submissions. Both align the trust boundary to "intent from the user-controlled origin" rather than "network position."

Schneier's broader argument is that trust-boundary errors are not bugs in the sense of typos or off-by-one mistakes; they are design errors that emerge from incomplete reasoning about who can act, when, and on whose behalf. Reading the SB6141 CSRF as a trust-boundary error rather than as a coding error is the framing that makes the CSRF teachable as a class rather than as a one-off curiosity.

Reading list (~1 hour)

1. Stuttard + Pinto, The Web Application Hacker's Handbook 2nd ed., Ch 13 ("Attacking Users: Cross-Site Request Forgery"). Academy library; calibre id 301. The canonical practitioner treatment.
2. OWASP, "Cross-Site Request Forgery (CSRF)" at https://owasp.org/www-community/attacks/csrf. The web reference. Brief; the discussion of CSRF tokens vs SameSite cookies is the prevention section.
3. MDN, "HTTP request methods" at https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods. Quick reference for GET vs POST vs PUT etc. CSRF on a GET endpoint is the easiest case; the SB6141 has GET endpoints for destructive actions.
4. Schneier A Hacker's Mind Ch 3 ("Hacking Trust"). Academy library calibre id 677.
5. Portswigger, "Burp Suite Community Edition documentation" at https://portswigger.net/burp/documentation/desktop. The Proxy tab section is the relevant part for Week 2.

Lecture outline (~50 min)

Part 1: HTTP at the wire level (15 min)

• A complete HTTP request is a method + a URL + a set of headers + (sometimes) a body. The minimum: GET /path HTTP/1.1\r\nHost: example.com\r\n\r\n.
• The session model. A "session" is the server's notion of which client is which. Servers maintain sessions via cookies (the most common pattern), HTTP basic authentication, bearer tokens, or implicit signals (network position; client certificate; mTLS). The SB6141 uses the implicit-signal pattern (network position).
• What a browser does with cookies. When a browser issues a request to a domain, it automatically attaches every cookie marked for that domain. The user does not have to do anything. The browser does it as a service.
• Why "automatically attaches" matters. A cross-origin page (different domain; the attacker's page) can include an HTML form whose action points at the target domain. When the form submits, the browser automatically attaches the target domain's cookies. The target sees a request that looks identical to a legitimate user-initiated request. This is CSRF.
• The same-origin policy prevents the attacker from READING the response (which is good; otherwise CSRF would also be a data-exfiltration vulnerability). It does not prevent the attacker from CAUSING the request (which is the bug).

Part 2: Burp Suite tour (15 min)

• Burp Proxy. Burp sits between your browser and the target. Every request and response passes through Burp; you can inspect, modify, or replay.
• Set up the proxy. Burp listens on 127.0.0.1:8080. Your browser is configured to route HTTP/HTTPS through that port. For the SB6141 admin interface (HTTP, no TLS) the setup is straightforward. (For HTTPS targets you would also import Burp's CA cert into the browser; not needed this week.)
• The Proxy "Intercept" tab. Pauses requests in flight so you can modify them. Useful for poking at parameters; intentionally OFF for normal browsing or the browser feels broken.
• The Proxy "HTTP history" tab. Logs every request/response pair. Right-click a request to replay it, send it to Repeater for modification, or export the raw bytes.
• Burp Repeater. Replays a request with whatever modifications you want. The practitioner's primary tool for verifying request behavior.
• What Burp does NOT do (in Community Edition). No active scanner. No intruder (limited). For ADV-101's reproduction work, Community is sufficient; the active-scanning features are PEN-101 territory.

Part 3: The SB6141 CSRF mechanic (15 min)

• The administrative interface lives at http://192.168.100.1/ by default. No authentication; the device's "authentication" is network position.
• The destructive action endpoints (the Longenecker advisory enumerates several; the most-cited is /goform/RgFactoryDefault for factory reset). These are GET or POST endpoints depending on the firmware version.
• The CSRF page. An attacker hosts a page at attacker.example.com/csrf.html with content like:

  <html><body>
  <img src="http://192.168.100.1/goform/RgFactoryDefault" />
  </body></html>
  
  

  When a victim on the same network as an SB6141 loads this page (or any page that includes this HTML), the browser issues the GET to 192.168.100.1/, the modem authenticates by network position, the destructive action runs.
• Manual reproduction with curl. You play the role of the browser the victim's hypothetical attacker has caused to issue the request. The curl invocation:

  curl -v http://192.168.100.1/goform/RgFactoryDefault
  
  

  Capture the response; observe the modem's behavior (LED reset; admin interface unreachable for ~60 seconds; once back, configuration defaults).
• Why we reproduce manually first. Before writing a tool (Week 4 onward), you need a transcript of the exact request that triggers the behavior. Manual reproduction with curl gives you that transcript. Tool-building is downstream; the wire shape is the prerequisite.

Part 4: Authorization at session start (5 min)

Before any HTTP traffic to the SB6141, write the per-session authorization line in your lab notebook:

Lab 2 session, 2026-MM-DD HH:MM. Target SB6141 unit <serial>; scope per signed cohort authorization (filed 2026-MM-DD); reproduction of VU#419568 CSRF; no testing outside the documented lab network.

The line is non-optional. The discipline is the discipline.

Disclosure-Ethics Sidebar

The CSRF reproduction in Week 2 sits at an interesting ethics intersection:

The same reproduction performed against a modem owned by someone else, without their written authorization, would be a federal crime under CFAA. The technical action is identical; the authorization context is what makes it research vs crime. This is the discipline ADV-101 teaches.

Labs (~3 hr)

Lab 2: Manual CSRF Reproduction (labs/lab-2-csrf-manual.md)

• Goal: reproduce the SB6141 CSRF (VU#419568) manually with curl plus a Burp Suite transcript
• Time: ~3 hr
• Artifact: lab-2-reproduction.md (transcript) + lab-2-burp-history.xml (Burp export) in ~/adv-101/lab-2/

Independent practice (~5 hr)

1. Burp Suite tour video (1 hr). PortSwigger's official "Burp Suite Community Edition" tour at https://portswigger.net/burp/training. Free; ~45 min. Plus 15 min hands-on with Burp pointed at http://example.com/.
2. Read Stuttard + Pinto Ch 13 in full (1.5 hr). The CSRF chapter. The chapter covers GET-based CSRF, POST-based CSRF, multistage CSRF, and the prevention mechanisms (tokens, SameSite). The SB6141 is the simplest case (GET-based, no auth); understanding the harder cases informs your Week 9 CVD draft.
3. Cross-origin form drill (1 hr). On your laptop, create two small HTML files: legitimate.html (a form pointing at http://example.com/) and attacker.html (a form pointing at the same place with hidden input values). View both in your browser; observe both submit identically from the server's perspective. (Use http://example.com/anything; the request goes out but no harm is done.) The exercise makes the CSRF mechanic concrete in your hands.
4. Cable Haunt context reading (1 hr). Read https://en.wikipedia.org/wiki/Cable_Haunt. Cable Haunt is a different CVE class (buffer overflow in Broadcom DOCSIS chipsets), affecting different cable modems via a CORS bypass + WebSocket vector. ADV-101 does not reproduce Cable Haunt as a graded lab, but the case is useful background: SB6141 CSRF is the "easy" case in the cable-modem-vulnerability landscape; Cable Haunt is the "hard" case. Knowing both gives perspective.
5. Schneier A Hacker's Mind Ch 4 (30 min). Continues the trust-boundary framing into political-system examples; cited indirectly in Week 9's CVD draft.

Reflection prompts (~30 min)

1. The CSRF mechanic depends on the browser automatically attaching credentials. Why did browsers ship this behavior in the first place? What useful feature was it intended to enable? (Hint: think about persistent sessions across tab closures.)
2. The SB6141 authenticates by network position. Name three other devices in your home or workplace that use the same authentication model. What is the threat model for each?
3. Burp Suite is one tool in a class; mitmproxy is another; browser DevTools is a third. After this week, when would you reach for Burp vs the others?
4. Your Lab 2 transcript shows a successful CSRF. What single change to the SB6141 firmware would have prevented it? (Hint: there is more than one correct answer.)
5. One thing from this week you want to know more about?

Adversary Diary (Week 2)

New entries:

• Burp Suite Community Edition (https://portswigger.net/burp/communitydownload). The HTTP-inspection workhorse. Proxy, Repeater, HTTP history are the three tabs you live in for ADV-101.
• curl with -v (verbose), -c FILE (write cookies to FILE), -b FILE (read cookies from FILE), --data-raw STRING (send a raw POST body) at https://curl.se/docs/manual.html. The replay tool.
• Browser DevTools Network tab (Chrome / Firefox). Lightweight alternative to Burp for read-only inspection.

What would a reviewer ask?

1. "Show me the exact request that triggered the destructive action. What HTTP method? What headers? What body?"
2. "Why did you use curl -v rather than curl? What does the -v flag tell you that the silent invocation does not?"
3. "Is your reproduction step idempotent? If you run the curl twice in a row, what happens?"

What comes next

Week 3 formalizes the lab network you used this week. You build the isolated-network setup with a network diagram, draft the per-session authorization log template, and write the scope-limit document. The Week 3 deliverable is the documentation that lets you (and the instructor) verify your future lab sessions are conducted within scope.