2.2 Application, Web, and Session Attack Vectors

Web Application Attacks and the Threat Surface

Publicly exposed web applications and RESTful APIs are important entry points for external threat actors. Web applications interact directly with sensitive backend relational databases, cloud object storage, and internal microservices. Securing and monitoring this perimeter requires SOC analysts to understand the current OWASP Top 10:2025 awareness categories while also learning the injection, access-control, XSS, CSRF, and session attacks named in the CSA scope. The exam topics and the OWASP list overlap, but they are not identical taxonomies.

---

SQL Injection (SQLi) Mechanics and Classification

SQL Injection (SQLi) occurs when untrusted user-supplied input is directly concatenated into a backend database query string without prior validation, sanitization, or parameterization. This flaw allows attackers to alter query execution logic, bypass authentication, exfiltrate sensitive tables, modify database records, or execute operating system commands.

1. In-Band (Classic) SQLi

The adversary utilizes the same communication channel to execute the injection and extract results:

• Error-Based SQLi: The attacker inputs malicious syntax designed to trigger deliberate database engine errors. When the database server returns verbose error messages (e.g., Microsoft OLE DB Provider for SQL Server: Conversion failed when converting the varchar value 'admin_hash' to data type int), the attacker extracts database names, table structures, and credential hashes directly from the error response.
• UNION-Based SQLi: Leverages the SQL UNION operator to append the results of an attacker-crafted query to the output of the original application query. To succeed, the attacker must satisfy two database requirements:
  1. The injected query must return the exact same number of columns as the original query (determined using iterative ORDER BY n-- clauses).
  2. The data types of corresponding columns in both queries must be compatible (e.g., ' UNION SELECT NULL, username, password_hash FROM sys_users--).

2. Inferential (Blind) SQLi

The web application does not display database errors or raw query outputs on the rendered page. Instead, the attacker reconstructs backend information character-by-character by asking a series of true/false questions:

• Boolean-Based Blind: The attacker injects conditions that evaluate to true or false. When true, the application returns normal content; when false, it returns an error page, missing data, or an alternate layout (e.g., ' AND SUBSTRING((SELECT user()), 1, 1) = 'r'--).
• Time-Based Blind: The attacker injects functions that instruct the database engine to sleep for a predetermined duration if a condition evaluates to true (e.g., '; IF (SELECT COUNT(*) FROM users) > 0 WAITFOR DELAY '0:0:5'-- on Microsoft SQL Server, or ' AND pg_sleep(5)-- on PostgreSQL). If the HTTP response time reflects this injected delay, the attacker confirms the injected hypothesis.

3. Out-of-Band (OOB) SQLi

Employed when the web application suppresses output, prevents error rendering, and rate-limits or buffers time-delayed queries. The attacker forces the database server to make an outbound network request (such as a DNS lookup or SMB connection) to an external server controlled by the attacker:

• Example: In Microsoft SQL Server, an attacker might abuse a feature such as xp_dirtree with a UNC path to trigger an outbound SMB name-resolution or authentication attempt. The exact technique and available functions depend on the database engine, permissions, and egress controls.

[Apache Web Server Access Log: UNION-Based SQL Injection Attempt]
198.51.100.42 - - [05/Sep/2026:11:22:15 +0000] "GET /catalog.php?cat_id=5%20UNION%20SELECT%20null,username,password_hash%20FROM%20admin_users--%20 HTTP/1.1" 200 4819 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

---

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) vulnerabilities occur when a web application accepts untrusted data and includes it in web pages delivered to other users without adequate input validation or context-aware output encoding. The injected script executes within the victim's browser session with the permissions of the vulnerable origin.

The Three Primary XSS Variants

1. Stored (Persistent) XSS: The malicious script is permanently stored within the target application's backend database (e.g., in blog comments, user profile bios, or support tickets). Whenever any user navigates to the affected page, the server retrieves the payload from storage and renders it into the HTML, causing the malicious script to execute automatically in every visitor's browser.
2. Reflected (Non-Persistent) XSS: The payload is embedded directly into an HTTP request parameter (such as a search query string or URL parameter). The web application reflects the parameter directly into the immediate HTTP response without storing it. The attacker distributes this payload by enticing victims to click a specially crafted hyperlink via phishing emails or social engineering.
3. DOM-Based XSS: The vulnerability resides entirely within the client-side JavaScript code rather than server-side rendering. The application reads user input from a Source (e.g., location.search, document.referrer, location.hash) and writes it into an execution Sink (e.g., document.write(), element.innerHTML, eval()) without sanitization. Because the payload is processed entirely in the browser, the malicious string may never be transmitted to the backend server, bypassing traditional web server log detection.

Defensive Countermeasures for XSS

• Context-Aware Output Encoding: HTML entities (< → <, > → >, " → ") are encoded prior to rendering in HTML body, attribute, JavaScript, or CSS contexts.
• Content Security Policy (CSP): An HTTP response header (e.g., Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedcdn.com) instructing modern browsers to execute scripts only from designated whitelisted origins and block inline <script> tags.
• HttpOnly Cookie Flag: Directs the browser not to expose the cookie through client-side APIs such as document.cookie. This blocks direct JavaScript reads of that cookie, although XSS can still perform actions in the victim session and steal data reachable through the page.

---

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) forces an authenticated user to perform unwanted state-changing actions on a web application in which they are currently authenticated. Web browsers automatically include stored authentication credentials (session cookies, Basic HTTP auth headers) with every HTTP request sent to a given domain, regardless of the origin of the request.

Attack Execution Scenario

1. A corporate user logs into their enterprise banking application (https://bank.enterprise.com) and retains an active session cookie.
2. In a separate browser tab, the user clicks a phishing link that opens https://attacker-site.com.
3. The malicious website contains an invisible HTML form that automatically submits an HTTP POST request to https://bank.enterprise.com/transfer with parameters amount=10000&to_account=987654.
4. The browser automatically attaches the user's valid session cookie to the outbound request. Because the banking application does not validate the origin or request authenticity, it executes the transfer as an authorized action.

CSRF Mitigation Architecture

• Anti-CSRF Synchronizer Tokens: The server generates a unique, cryptographically random, unpredictable token tied to the user's session and embeds it within legitimate forms. Upon submission, the server validates that the submitted token matches the session value. Because a cross-origin attacker cannot read the token due to the Same-Origin Policy (SOP), forged requests are rejected.
• SameSite Cookie Attribute:
  • SameSite=Strict: The browser refuses to send the cookie in any cross-site request (e.g., following an external link).
  • SameSite=Lax: Cookies are withheld on cross-site subrequests (images, iframes), but sent when a user navigates to the origin site via top-level GET navigation.

---

Broken Access Control and Insecure Direct Object References (IDOR)

Insecure Direct Object References (IDOR) occur when an application exposes a reference to an internal database key, record identifier, or filename in a request parameter without validating whether the requesting user is authorized to access that object.

• Parameter Tampering Example: A user accesses their medical record at https://portal.health.org/api/v1/records?patient_id=40281. By altering the patient_id parameter to 40282, the application displays another patient's confidential health data because the backend API checks only that the requester is authenticated, but fails to check object-level authorization.
• Horizontal vs. Vertical Privilege Escalation:
  • Horizontal Privilege Escalation: An attacker accesses records or performs actions belonging to another user of the same privilege tier.
  • Vertical Privilege Escalation: A standard user tampers with parameters (e.g., altering role=user to role=admin in JSON bodies or cookie tokens) to access administrative capabilities.

---

Session Hijacking vs. Session Fixation

Session identifiers allow stateless HTTP applications to maintain state across multiple requests. Compromising a session token bypasses primary authentication mechanisms, including Multi-Factor Authentication (MFA).

[Comparison of Cookie Security Flags]
Set-Cookie: JSESSIONID=abc123xyz789; Path=/; Secure; HttpOnly; SameSite=Strict
- Secure:         Restricts transmission strictly to encrypted HTTPS channels.
- HttpOnly:       Blocks client-side scripts (JavaScript document.cookie) from reading the cookie.
- SameSite=Strict: Prevents transmission in cross-site requests, mitigating CSRF.