Chapter 66 — Project 3: an advanced web assessment to ATO/RCE

Brief

Do a full advanced assessment against a target you deploy, chaining at least four of Part 6's advanced classes — request smuggling/cache poisoning, XXE/SSRF, a memory/logic bug (prototype pollution, deserialization, or SSTI), a race condition, and a federated-identity flaw — into account takeover or remote code execution, with a professional report and complete remediation. This extends Part 6 Ch 40's capstone with a REQUIRED minimum chain length and a REQUIRED federated-identity link, and folds in Part 9's program discipline: every finding goes through Ch 59's prioritisation, not just a report.

Tasks

   1. TARGET: deploy "SecureShop-vuln" (or an equivalent target you
      control) with, at minimum: a front-end/back-end pair susceptible to
      request smuggling, an XML-processing endpoint, an SSRF-capable
      feature, a Node service using unsafe merge, a "once" operation with
      a check-then-act race, an SSTI or deserialization sink, a file
      upload feature, and a SAML or OAuth integration on an older library.

   2. RECON, FIND, CHAIN (Part 6 Ch 40's method) -- with the ADDED
      requirement that the chain includes:
      [ ] at least ONE protocol-level bug (smuggling, cache poisoning, or
          XXE/SSRF).
      [ ] at least ONE logic/memory-shape bug (prototype pollution,
          deserialization, or SSTI).
      [ ] at least ONE race condition.
      [ ] the federated-identity flaw (SAML XSW, or an OAuth
          redirect_uri/account-linking issue) as either the ENTRY point
          or the FINAL escalation step.

   3. PRIORITISE (Part 9 Ch 59) -- don't just report; run every finding
      through the SAME CVSS+EPSS-style thinking (adapt EPSS's spirit --
      "how likely is this specific class to be found/exploited given
      what's public about it" -- since these are app-specific, not
      CVE-tracked) and asset-criticality scoring used for the rest of
      your vulnerability backlog. Produce a ranked list, not just a
      narrative.

   4. REPORT AND REMEDIATE (Part 6 Ch 40 + Part 9 Ch 58's SDLC gates)
      [ ] the full professional report with the chain diagrammed as an
          attack path (Part 1 Ch 1's notation).
      [ ] fix every link; add the SPECIFIC SAST/DAST rule (Part 9 Ch 58)
          that would have caught the root-cause class in review, not just
          a one-off code fix -- e.g. a Semgrep rule for the exact unsafe-
          merge pattern that enabled the prototype-pollution link.
      [ ] a regression test per fix, PLUS the new detection rule (Part 8
          Ch 51) for the exploitation pattern itself.

Deliverable

~/sec-lab/adv/projects/p3-webchain/report.md: recon notes, the required four-class chain diagrammed and evidenced, the prioritised finding list, the full remediation (code fixes + regression tests + a new SAST/DAST rule + a new detection rule), and re-test evidence the chain is dead at every link.

Definition of done

• A chain meeting all four required-class criteria, ending in ATO or RCE.
• Findings prioritised with a documented scoring rationale, not just severity labels.
• Every link fixed, with a regression test, a new SAST/DAST rule for the root-cause pattern, and a live-validated detection rule for the exploitation pattern.
• Full re-test showing the chain dead at every link.

Rubric (/100)

   Chain meets all four required-class criteria .......... 25
   Evidence quality ...................................... 10
   Prioritisation rationale .............................. 10
   Report professionalism ................................ 10
   Remediation: code fix + regression test per link ...... 20
   New SAST/DAST rule + new detection rule, validated .... 20
   Re-test proves every link broken ...................... 5