2.4 Given a scenario, recommend controls to mitigate attacks and software vulnerabilities.
📘CompTIA CySA+ (CS0-003)
Definition:
Cross-Site Scripting (XSS) is a type of security vulnerability that allows an attacker to inject malicious code (usually JavaScript) into a website or web application. This malicious code runs in the browser of anyone who visits the affected site, giving attackers the ability to steal sensitive information, hijack sessions, or perform actions on behalf of the user.
In short: XSS lets attackers make your browser do things you didn’t intend, by tricking a website into sending you malicious code.
Types of XSS
1. Reflected XSS (Non-Persistent XSS)
How it works:
- The attacker sends a malicious link (URL) to a victim.
- When the victim clicks the link, the malicious code is “reflected” back by the website in the response.
- The attacker’s code executes immediately in the victim’s browser.
Example in IT terms:
- A web form asks for your name, like a search box or contact form.
- The website shows your input on the page, e.g., “Hello, [Your Name]!”
- If the website does not properly check the input, an attacker could input something like
<script>alert('Hacked!')</script>. - When a user clicks the crafted link, their browser runs this script, which could steal cookies or login info.
Key Points for Exam:
- Reflected XSS requires user interaction (clicking a link).
- It is usually delivered through URLs, forms, or query parameters.
- Attack is temporary – it happens only when the link is used.
2. Persistent XSS (Stored XSS)
How it works:
- The attacker submits malicious code to a website, and the website stores it in its database.
- When any user visits the page or loads the content, the malicious code runs automatically.
Example in IT terms:
- A forum allows users to post messages.
- An attacker posts:
<script>stealCookies()</script> - Every user who opens that post triggers the script in their browser.
- This can steal session cookies, redirect users, or modify displayed content.
Key Points for Exam:
- Persistent XSS is more dangerous because it affects multiple users automatically.
- It often targets websites with user-generated content: forums, comment sections, blogs, or chat applications.
- Stored in server-side databases, so the attack persists until the data is cleaned.
How to Mitigate XSS
Cybersecurity analysts need to know defense strategies. Here are the key mitigations:
- Input Validation & Output Encoding:
- Validate user input to allow only expected characters.
- Encode output so any injected code is treated as text, not executable code.
<script>becomes<script>in the browser. - Content Security Policy (CSP):
- A browser-level defense that restricts what scripts can run on a page.
- Can prevent malicious scripts from executing even if injected.
- Use Secure Frameworks:
- Modern web frameworks (React, Angular, Django) have built-in protections against XSS.
- HTTPOnly Cookies:
- Mark cookies as HTTPOnly so JavaScript cannot access them, reducing the impact of XSS stealing sessions.
- Regular Security Testing:
- Conduct vulnerability scans or penetration tests to detect XSS.
- Tools like Burp Suite, OWASP ZAP, or Nessus can help.
Quick Comparison Table for Exam
| Feature | Reflected XSS | Persistent XSS |
|---|---|---|
| Requires user action? | Yes (clicking link) | No (runs automatically) |
| Where code is stored? | Temporary (in URL/request) | Permanent (server database) |
| Typical targets | Search forms, query parameters | Forums, comment sections, chat apps |
| Impact | Individual user | Multiple users |
| Mitigation | Input validation, CSP | Input validation, output encoding, secure frameworks, CSP |
✅ Exam Tips:
- Remember: Reflected = one-time, click needed; Persistent = stored, auto-executes.
- Mitigations mostly revolve around input validation, output encoding, and proper security policies.
- Always think of XSS as attacker controlling code in users’ browsers, not on the server.
