D8 — Beyond Injection: XSS, CSRF, Broken Authentication, Maturity Models

Lesson 11 covered SQL injection as the canonical code/data confusion vulnerability. This lesson covers three more classes CISSP expects you to distinguish precisely from each other and from injection — plus a step back from individual vulnerabilities entirely, to how an organization measures whether its process for preventing them is actually maturing.

Cross-Site Scripting (XSS) — three distinct variants

XSS is injection's close cousin: instead of confusing a database's code and data, it confuses a browser's code and data — attacker-supplied input gets executed as script in a victim's browser. Three variants, distinguished by where the malicious script comes from and where it executes:

• Stored XSS — the malicious script is saved on the server (e.g. in a comment field) and served to every subsequent visitor who views that content. Highest impact: affects any visitor without them doing anything unusual.
• Reflected XSS — the malicious script is part of the request itself (e.g. a crafted URL parameter) and is immediately reflected back into the response without being stored. Requires tricking a specific victim into clicking a crafted link.
• DOM-based XSS — the vulnerability exists entirely in client-side JavaScript that unsafely processes data from the page's own DOM (e.g. the URL fragment), without the malicious payload ever necessarily touching the server at all.

The shared root cause across all three: untrusted input rendered into a page without proper output encoding, letting it be interpreted as executable script rather than inert data — the same code/data confusion pattern as Lesson 11's SQL injection, applied to a browser instead of a database.

CSRF — a fundamentally different exploit

Cross-Site Request Forgery (CSRF) is often mentioned alongside XSS but exploits something structurally different: it doesn't inject any malicious script at all. Instead, it tricks a victim's browser into submitting an authenticated request to a site the victim is already logged into, using the victim's own valid session — the victim's browser automatically attaches their session cookie, and the server has no way to tell the forged request apart from one the victim intended to make.

The key distinction: XSS is about executing attacker script in the victim's browser; CSRF is about the victim's own authenticated browser unknowingly performing an action the attacker wanted, with no script injection required at all. This is why CSRF's defense (anti-CSRF tokens tied to the user's session, verified on every state-changing request) is completely different from XSS's defense (output encoding) — they're not variations of the same fix.

Broken authentication — a different layer entirely

Broken authentication covers weaknesses in how a system verifies identity itself: session tokens that don't expire, predictable session identifiers, credentials transmitted or stored insecurely, or missing account lockout allowing credential-stuffing attacks to run unchecked. This is distinct from injection and XSS in a specific way worth naming: injection and XSS are about what a request can do once it reaches the application; broken authentication is about whether the system can reliably establish who is making the request in the first place — a failure here can undermine every other control downstream, since access control, audit logging, and authorization all assume the system correctly knows who's asking.

Maturity models: measuring the process, not a single finding

CMMI (Capability Maturity Model Integration) and SAMM (Software Assurance Maturity Model) both assess how mature an organization's secure development process is — not whether a specific application currently has vulnerabilities — but structure that assessment differently. CMMI defines five graduated maturity levels: Initial (ad hoc, unpredictable, reactive), Managed (basic project-level discipline exists), Defined (processes standardized and documented organization-wide, not just per-project), Quantitatively Managed (process performance controlled with actual data, not intuition), and Optimizing (continuous, proactive process improvement). SAMM instead organizes around five business functions — Governance, Design, Implementation, Verification, and Operations — each broken into specific security practices assessed somewhat independently, rather than one single organization-wide level. Different structures, same underlying question: a maturity model assessment answers "how consistently and systematically does this organization prevent, find, and fix security issues across all its projects," not "does this specific application have a bug right now." An organization can pass every vulnerability scan on its current applications while still scoring at CMMI Level 1 (Initial) or low across SAMM's functions, if its process for consistently preventing the next vulnerability is ad hoc and person-dependent rather than institutionalized.

The CISSP mindset: manager vs technician

A penetration test finds a reflected XSS vulnerability in one form field. The developer adds output encoding to that specific field and closes the ticket.

The technician answer: the specific finding is fixed, verified by retesting the same field, ticket closed.

The manager (CISSP) answer: ask whether this is an isolated instance or a symptom of the same output-encoding gap existing in every other form field across the application (and possibly other applications built the same way) — precisely Lesson 11's twelve-instances reasoning, applied here to XSS instead of SQL injection. The deeper question a maturity-model lens raises: does the secure development process systematically ensure output encoding on every user-facing field going forward (a SAMM/CMMI-level process fix — a coding standard, a linter rule, mandatory code review coverage), or does preventing recurrence depend entirely on each individual developer independently remembering this specific lesson? Fixing the one finding closes the ticket; fixing the process is what actually prevents the next one.