Authentication & Web Attacks: Two Independent Factors, CSRF, and XSS

Many security workflows depend on independent factors: something you have, something you know, or something you are. In practice, applications sometimes combine two independent “checks” (e.g., login plus a second challenge) and also rely on browser/network boundaries to prevent web attackers from misusing a victim’s session.

This course section connects those ideas to three common web security issues:

1. Two-factor authentication (2FA) as a deliberate second factor,
2. Cross-site request forgery (CSRF) as an attacker abusing ambient authority (e.g., cookies) without breaking same-origin,
3. Cross-site scripting (XSS) as attacker-controlled script execution in a victim’s origin, and
4. the common confusion of “cross-site scoring scripting” — commonly meant as Cross-site scripting again (or “XSS”) and why there is no standard widely-used vulnerability category with that exact name.

We’ll treat (i) as a designed two-factor mechanism, while (ii)–(iv) are attacks that exploit missing/incorrect trust separation.

Key concepts

• Factor
• Authenticator
• Ambient authority
• Same-origin policy
• Input-to-output encoding

1) Two-Factor Authentication (2FA) as “two independent factors”

Two-factor authentication is an authentication scheme in which a user must successfully present two independent factors to log in. The independence goal is critical: compromising one factor should not automatically grant access.

In modern guidance, a “second factor” is typically implemented via a second authenticator (e.g., one-time codes from an authenticator app, a hardware security key, or a push-based challenge), after the primary login step.

A robust implementation typically includes:

• Rate limiting and lockout policies for the login and challenge flows.
• Binding the second-factor challenge to the correct session and relying on server-side verification.
• Defending against replay and man-in-the-middle scenarios where applicable.
• Ensuring the user experience doesn’t accidentally weaken the factor separation (e.g., skipping verification in edge cases).

Threat model connection

2FA reduces the chance that an attacker can authenticate only by stealing one credential. In other words, it enforces a second check that’s not fully determined by a single compromised secret.

Mermaid: factor separation and authorization flow

[CalloutBlock]
type: "tip"
title: "Pro Tip"
content: "Think of 2FA as adding an additional verification gate. The key is independence: the second factor should not be derivable from the first alone."

2) Cross-Site Request Forgery (CSRF)

CSRF occurs when an attacker tricks a victim’s browser into sending an authenticated request to a target site where the victim already has a session. Crucially, the attacker often does not need to read the response; they only need the request to be accepted by the server.

CSRF is possible largely because browsers automatically include relevant credentials:

• Cookie-based sessions
• HTTP authentication headers (depending on configuration)
• Other ambient credentials

If an endpoint is vulnerable, the attacker can cause a victim’s browser to issue a state-changing request (e.g., “transfer funds”) without the victim’s intent.

Common vulnerable conditions

• State-changing actions rely only on cookies and lack request-specific verification.
• No CSRF token (or no server-side validation of it).
• Same-site mitigations are missing or misconfigured.

Core defense idea: bind requests to user intent

The standard approach is to include a CSRF token:

• The server creates a per-session/per-request token.
• The browser includes that token in a form field or custom header.
• The server verifies the token for state-changing operations.

This makes attacker-forged requests fail because attackers can’t forge the token (assuming correct implementation).

Mermaid: CSRF with and without token verification

[CalloutBlock]
type: "warning"
title: "CSRF ≠ XSS"
content: "CSRF is about request forgery using the victim’s existing session. XSS is about executing attacker-controlled script in the victim’s origin."

3) Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is the injection and execution of attacker-controlled script in the context of another user’s session within a vulnerable origin.

Unlike CSRF, XSS is directly about script execution. If an attacker can inject script into an application that later renders it unsafely, the attacker can often:

• Read/modify page content
• Call APIs using the user’s credentials (subject to browser controls)
• Perform actions as the victim (similar outcome to CSRF but with more power)

XSS is typically categorized as:

• Reflected XSS: payload appears immediately in a response.
• Stored XSS: payload is saved (e.g., in a database) and served later.
• DOM-based XSS: vulnerability is in client-side JavaScript logic rather than server rendering.

Defense-in-depth for XSS

The central protection strategy is:

• Treat all untrusted data as data, not code.
• Use context-aware output encoding:
  • HTML context escaping
  • Attribute escaping
  • JavaScript string escaping
  • URL encoding
• Avoid dangerous sinks (innerHTML with untrusted content, eval, etc.).
• Deploy a strong Content Security Policy (CSP) to reduce script execution impact.

Mermaid: “untrusted input → safe encoding → safe output”

[CalloutBlock]
type: "tip"
title: "Pro Tip"
content: "Always encode for the exact context where data is placed (HTML, attribute, JS string, URL). One blanket sanitizer often fails."

4) “Cross-site scoring scripting” — resolving the term

The phrase “cross-site scoring scripting” is not a standard, widely recognized vulnerability name in mainstream security taxonomies. In many courses and informal notes, it appears to be a miswording for Cross-site scripting (XSS) (already covered), or sometimes a confusion with:

• request forgery (CSRF),
• or client-side injection issues broadly.

In this section, we interpret (iv) as XSS, because it best matches the “cross-site … scripting” wording and the usual pairing with CSRF and 2FA in introductory questions.

Input validation
Output encoding
DOM-based XSS
Stored XSS