XSS (Reflected)

Question 1

Q1: What is Reflected XSS?

Answer 1

A1: When malicious input is reflected from the server into the page and executed immediately in the victim’s browser.

Question 2

Q2: Why does Reflected XSS happen?

Answer 2

A2: Because untrusted input is inserted into the page without validation or escaping, especially in dynamic HTML or JS contexts.

Question 3

Q3: What’s an example payload for Reflected XSS?

Answer 3

A3:

alert(1)

Question 4

Q4: What JavaScript sinks are dangerous in Reflected XSS?

Answer 4

A4: document.write(), innerHTML, eval(), setTimeout(), location.href, and inline event handlers.

Question 5

Q5: Name 3 real-world consequences of Reflected XSS

Answer 5

A5:
1. Stealing session cookies
2. Defacing pages
3. Redirecting to phishing sites

Question 6

Q6: How can you detect Reflected XSS using Burp Suite?

Answer 6

A6: Inject test payloads like

alert(1)

into URL/query parameters and inspect the reflected response or rendered output.

Question 7

Q7: What are two solid prevention methods?

Answer 7

A7:

1. Escape output properly based on context (HTML/JS/URL)
2. Use frameworks that auto-sanitize (React, Angular, etc.)

Question 8

Q8: What’s a good metaphor for remembering Reflected XSS?

Answer 8

A8: Like throwing a boomerang with a knife — and it comes back to stab the user.

Question 9

Q9: What HTTP request type is most common for Reflected XSS?

Answer 9

A9: GET

Question 10

Q10: How does CSP help with XSS?

Answer 10

A10: Content Security Policy blocks inline scripts and restricts script sources, mitigating script injection even if the payload lands.