Web Application Vulnerabilities
Security weaknesses specific to web applications including SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and other input validation failures. These vulnerabilities allow attackers to steal data, hijack sessions, or compromise web servers.
Understanding Web Application Vulnerabilities
Web applications present unique security challenges because they accept input from untrusted users over the internet. Most web vulnerabilities stem from a single root cause: trusting user input without proper validation.
Core web vulnerability types: • Injection attacks — SQL injection, command injection • Cross-site attacks — XSS, CSRF • Authentication flaws — Broken authentication, session management • Data exposure — Sensitive data leakage
The OWASP Top 10 tracks the most critical web application security risks and is an essential reference for web security.
Why This Matters for the Exam
Web application vulnerabilities are among the most commonly exploited and heavily tested on SY0-701. SQL injection and XSS appear frequently in exam scenarios.
Understanding these vulnerabilities is essential because web applications are the public face of most organizations—they're accessible from anywhere and handle sensitive data.
The exam tests both recognition (identifying vulnerability types from descriptions) and remediation (knowing appropriate defenses).
Deep Dive
SQL Injection (SQLi)
Inserting malicious SQL code through user input to manipulate database queries.
How SQL Injection Works:
Vulnerable Code:
- •```sql
- •query = "SELECT * FROM users WHERE username='" + input + "'";
- •```
Malicious Input:
- •```
- •' OR '1'='1
- •```
Resulting Query:
- •```sql
- •SELECT * FROM users WHERE username='' OR '1'='1'
- •```
- •This returns ALL users because '1'='1' is always true.
SQL Injection Impact:
- •Data theft (dump entire database)
- •Data modification (change records)
- •Authentication bypass (login as any user)
- •Database destruction (DROP tables)
- •Command execution (in some cases)
SQL Injection Types:
| Type | Description |
|---|---|
| In-band | Results returned in application response |
| Blind | No visible results; infer from behavior |
| Out-of-band | Results sent to attacker-controlled server |
SQL Injection Defenses:
- •Parameterized queries (prepared statements)
- •Input validation (whitelist allowed characters)
- •Stored procedures (with parameterization)
- •Least privilege (database accounts)
- •WAF (Web Application Firewall)
Cross-Site Scripting (XSS)
Injecting malicious scripts into web pages viewed by other users.
How XSS Works:
- 1.Attacker injects JavaScript into web page
- 2.Victim visits page containing malicious script
- 3.Script executes in victim's browser
- 4.Script can steal cookies, credentials, or perform actions
XSS Types:
Reflected XSS
- •Malicious script in URL or form input
- •Server reflects input back in response
- •Victim clicks malicious link
- •One-time, per-request attack
Stored XSS
- •Malicious script stored on server (database, comments)
- •Served to all users viewing the content
- •Persistent and affects many users
- •More dangerous than reflected
DOM-based XSS
- •Vulnerability in client-side JavaScript
- •Server never sees malicious payload
- •Executed entirely in browser
XSS Impact:
- •Session hijacking (steal cookies)
- •Credential theft (fake login forms)
- •Defacement (modify page content)
- •Malware distribution
- •Keylogging
XSS Defenses:
- •Output encoding (escape special characters)
- •Input validation (reject or sanitize)
- •Content Security Policy (CSP)
- •HTTPOnly cookies (inaccessible to JavaScript)
- •X-XSS-Protection header
Cross-Site Request Forgery (CSRF)
Tricking authenticated users into performing unintended actions.
How CSRF Works:
- 1.User authenticates to target site
- 2.User visits attacker's site (while still logged in)
- 3.Attacker's site sends request to target
- 4.Target processes request using user's session
- 5.Action performed without user's knowledge
CSRF Example:
- •User logged into bank. Visits malicious page containing:
- •```html
- •
- •```
- •Bank processes transfer using user's existing session.
CSRF Defenses:
- •Anti-CSRF tokens (unique per request)
- •SameSite cookie attribute
- •Referer header validation
- •Re-authentication for sensitive actions
Other Web Vulnerabilities
Insecure Direct Object References (IDOR)
- •Accessing objects by manipulating IDs
- •Example: /user/profile?id=123 → change to id=124
- •Access other users' data
Server-Side Request Forgery (SSRF)
- •Tricking server into making requests
- •Access internal resources
- •Bypass firewalls
XML External Entity (XXE)
- •Exploiting XML parsers
- •Read local files
- •Server-side request forgery
Directory Traversal
- •Using ../ to access files outside web root
- •Read sensitive files
- •Example: /file?name=../../../etc/passwd
Input Validation Summary
| Vulnerability | What's Injected | Where |
|---|---|---|
| SQL Injection | SQL code | Database queries |
| XSS | JavaScript | Web pages |
| Command Injection | OS commands | System calls |
| LDAP Injection | LDAP queries | Directory services |
| XML Injection | XML/XXE | XML parsers |
How CompTIA Tests This
Example Analysis
Scenario: A web application displays user comments without encoding. An attacker posts a comment containing: ``. Every user who views this comment has their session cookie sent to the attacker.
Analysis - Stored XSS:
Why It's Stored XSS: • Malicious script saved to database (comment) • Served to ALL users viewing comments • Persistent—affects everyone, not just one victim • Script executes in each victim's browser
Attack Flow: 1. Attacker posts comment with JavaScript 2. Server stores comment in database 3. Other users request page with comments 4. Server serves malicious script as part of page 5. Script runs in victims' browsers 6. Cookies exfiltrated to attacker's server
Defense Measures: • Output encoding — Convert < to < before display • Input validation — Reject or sanitize script tags • CSP — Restrict script execution sources • HTTPOnly cookies — Prevent JavaScript access to session
Key insight: The vulnerability is trusting user input (the comment) and reflecting it without sanitization. All injection attacks stem from this fundamental flaw.
Key Terms to Know
Common Mistakes to Avoid
Exam Tips
Memory Trick
"SCIX" - Major Web Vulnerabilities
- •SQL injection (attack database)
- •CSRF (trick authenticated users)
- •IDOR (access other users' data)
- •XSS (execute scripts in browsers)
- •XSS Type Memory:
- •Reflected = Returned once (via URL)
- •Stored = Saved permanently (in database)
- •DOM = Done in browser (no server)
- •Injection Defense Memory:
- •SQL → Parameterized queries
- •XSS → Encoding output
- •CSRF → Tokens (anti-CSRF)
Root Cause: ALL injection = Trusting untrusted input Defense = Validate IN, Encode OUT
Test Your Knowledge
Q1.An attacker enters ' OR 1=1-- into a login form's username field and gains access without a valid password. This exploits:
Q2.Malicious JavaScript stored in a web application's comment section executes in every visitor's browser. This is:
Q3.What is the PRIMARY defense against SQL injection attacks?
Want more practice with instant AI feedback?
Practice with AIContinue Learning
Ready to test your knowledge?
Practice questions on web application vulnerabilities and other Objective 2.3 concepts.