Attacks and Exploits · Topic 4 of 10
Web Application Attacks
Recognise SQL injection, cross-site scripting, directory traversal and other OWASP Top 10 web flaws, their log indicators and standard code defences.
- 6 min
- SQL injection is fixed by parameterised queries, with validation and least privilege as extra layers.
- XSS has reflected, stored and DOM-based forms, and output encoding and a CSP are core defences.
- Directory traversal escapes a folder with path manipulation, and the fix is path validation and limited file rights.
What it is
Web application attacks exploit flaws in how a website or web service handles input, sessions and access. They are a common route into data held by internet-facing applications.
The Open Worldwide Application Security Project (OWASP) publishes the OWASP Top 10, a ranked list of the most serious web application risk categories. The exam expects you to recognise the main attacks from a description or a log line and to know the fix.
How it works
Most of these flaws share one cause: the application mixes untrusted data with instructions. The defence is to keep data and commands apart and to check every input on the server.
SQL injection
Structured Query Language (SQL) injection happens when user input is placed into a database query in a way that lets the input change the meaning of the query. The result can be exposed records, altered data or, in some setups, command execution on the database server.
| Type | How it shows |
|---|---|
| In-band (error-based, union-based) | Results or error messages appear in the page |
| Blind (boolean or time-based) | No data shown, so the attacker infers answers from page behaviour or response delay |
| Out-of-band | Data leaves through a different channel, such as a network request from the database |
Indicators are database error messages in responses, odd quote characters or SQL keywords in request parameters in the web server log, and unusually slow responses. The fix is parameterised queries (prepared statements), which treat input only as data.
# Python: safe pattern, input is passed as a parameter, not joined into the text
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))Other defences are input validation, least-privilege database accounts, and hiding detailed error messages. A web application firewall (WAF) adds a layer but does not replace secure code. The tool sqlmap automates the testing of injection flaws and is used within scope.
Cross-site scripting (XSS)
In cross-site scripting, an application sends untrusted input to a browser without proper handling, so the browser runs attacker-controlled script in the site's context. The script can steal session tokens, change what the user sees or act as the user.
| Type | Where the script comes from |
|---|---|
| Reflected | Part of the request, returned in the immediate response, often through a crafted link |
| Stored (persistent) | Saved by the application, such as in a comment, and shown to every visitor |
| DOM-based | Created by page script in the browser, with no server-side reflection |
The Document Object Model (DOM) is the browser's live representation of the page. The main fixes are output encoding that matches the context, input validation, a Content Security Policy (CSP) that restricts script sources, and cookie flags such as HttpOnly, which hides cookies from script.
Directory traversal
Directory traversal, also called path traversal, lets an attacker read files outside the intended folder by manipulating a file path parameter. A related issue is file inclusion, where an application loads a file or remote resource chosen by the user.
In logs, look for repeated "dot dot slash" sequences in request parameters, in plain or URL-encoded form (%2e%2e%2f). The fix is to avoid using user input in file paths, to resolve and check the final path against an allowed folder, and to run the web server with limited file permissions.
Other flaws worth knowing
| Flaw | Idea | Defence |
|---|---|---|
| Command injection | Input reaches an operating system command | Avoid shell calls, validate input |
| Cross-site request forgery (CSRF) | A logged-in browser is tricked into sending an unwanted request | Anti-CSRF tokens, SameSite cookies |
| Server-side request forgery (SSRF) | The server is made to request internal or metadata addresses | Allow lists, network egress control |
| Broken access control and insecure direct object reference (IDOR) | Changing an identifier shows another user's data | Server-side authorisation checks on every request |
| XML external entity (XXE) | An XML parser loads external content | Disable external entities |
| Insecure deserialization | Untrusted serialized data is processed | Avoid or verify serialized input |
| Session and authentication flaws | Weak tokens, no timeout | Strong session handling, MFA |
More web flaws
| Flaw | Idea | Defence |
|---|---|---|
| Collision attack | Two different inputs producing the same hash, a risk with weak functions such as MD5 or SHA-1 | Use strong modern hash functions |
| Server-side template injection | User input evaluated by a server-side template engine | Do not render user input as a template, and sandbox the engine |
| Application programming interface (API) abuse | Broken object-level authorisation, excessive data exposure or missing rate limits, as in the OWASP API Top 10 | Per-request authorisation checks, minimal data, rate limiting |
| JSON Web Token (JWT) manipulation | Unsigned or "none" algorithm tokens, weak signing keys, or unchecked claims | Strict signature validation and verified claims |
Tools
Burp Suite and ZAP (Zed Attack Proxy) are intercepting proxies for manual and automated testing. Nikto checks server configuration, and tools like Gobuster find hidden paths. A tester combines them with manual reasoning, because logic flaws need human judgement.
The exam often hides the fix in the verb. "Parameterise" points to SQL injection, "encode output" to cross-site scripting, and "validate the final path" to traversal.
Two more tools appear in the outline. Postman is an application programming interface (API) client used to build and replay API requests during testing. Wfuzz is a web fuzzer that replaces a marker in a request with values from a word list to discover parameters and paths.
What to remember for the exam
- SQL injection is fixed by parameterised queries, with validation and least privilege as extra layers.
- XSS has reflected, stored and DOM-based forms, and output encoding and a CSP are core defences.
- Directory traversal escapes a folder with path manipulation, and the fix is path validation and limited file rights.
- CSRF abuses the user's logged-in browser, and anti-CSRF tokens defend against it.
- SSRF makes the server fetch internal resources, including cloud metadata.
- IDOR is a broken access control flaw fixed by server-side authorisation checks.
- Blind SQL injection shows no data and relies on behaviour or timing.
- A WAF helps but does not replace secure coding.
Common mistakes
Mixing up XSS and CSRF. XSS runs script in the victim's browser, whereas CSRF sends a forged request that the browser authenticates.
Relying on client-side validation. Browser checks can be bypassed, so the server must validate again.
Believing a WAF fixes the bug. It filters known patterns, and the vulnerable code remains.
Treating stored and reflected XSS as the same. Stored XSS affects every visitor, while reflected needs the victim to follow a crafted request.
Reporting without impact. A finding should explain what data or action is exposed in this application.
Check yourself
What is the primary defence against SQL injection?
Parameterised queries (prepared statements).
Which XSS type is saved by the application and served to many users?
Stored (persistent) XSS.
What does a CSP do?
It restricts which sources of script and content the browser may load, which limits the effect of XSS.
Topic 4 of 10 in Attacks and Exploits
Test yourself on Attacks and Exploits
The full CompTIA PenTest+ PT0-003 question bank has 653 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.