312-50 Question 300
Single answer▪ Web App ThreatsDuring a sanctioned web application assessment, you test an e-commerce site's search function at /products?category=shoes&q=running. The application reflects the q parameter directly into the HTML response. When you submit the payload , the page returns your input as <script>alert(1)</script> and no script executes. However, when you submit the payload "><svg/onload=alert(1)>, the browser executes JavaScript. Which issue best explains this behavior?
- A
The application is vulnerable to reflected XSS because output encoding is applied inconsistently and can be bypassed in an HTML attribute/context-breaking scenario
- B
The application is vulnerable to stored XSS because the payload is being saved in the backend database and rendered to other users
- C
The application is vulnerable to SQL injection because special characters in the q parameter alter server-side query execution
- D
The application is secure against XSS because angle brackets were encoded in the first test, proving input validation is working correctly
Show answer and explanation
Correct answer: A
Explanation
The best answer is the reflected XSS option. The key clue is that attacker-controlled input from the q parameter is immediately reflected in the HTTP response and executed only when a payload is crafted to break out of the existing rendering context. This is typical of reflected XSS caused by improper contextual output encoding rather than simple input filtering. Modern guidance from the OWASP Cross Site Scripting Prevention Cheat Sheet emphasizes context-aware output encoding and avoiding reliance on blacklist-style filtering. For example, data placed into HTML attributes must be encoded for attribute context, not just HTML body context. OWASP also notes that dangerous contexts, such as inline event handlers and mixed parsing contexts, are frequent sources of bypasses when developers apply incomplete defenses. In a CEH-style assessment, the correct interpretation is that the application has reflected XSS due to inconsistent or incorrect output encoding for the actual sink where the untrusted data is rendered.
- A. Correct.
Correct. This is a classic reflected cross-site scripting scenario. The first payload being encoded may suggest some filtering or context-aware handling, but the second payload demonstrates that the application fails to safely encode untrusted data in the actual rendering context. The leading quote breaks out of an existing attribute or HTML context, and the injected SVG onload handler executes script in the victim's browser. This indicates inconsistent or context-inappropriate output encoding, which is a common root cause of reflected XSS.
- B. Incorrect.
Incorrect. Stored XSS requires the malicious payload to be persisted by the application, such as in a database, comment field, profile, or log, and later served to other users. In this scenario, the issue appears immediately in the search response based on the current request parameter, which aligns with reflected XSS rather than stored XSS.
- C. Incorrect.
Incorrect. SQL injection affects backend database queries, typically causing changes in query logic, data exposure, authentication bypass, or database errors. The observed behavior here is client-side script execution in the browser caused by unsafe reflection into HTML, which is characteristic of XSS, not SQL injection.
- D. Incorrect.
Incorrect. Encoding one payload does not prove the application is secure. XSS prevention depends on correctly handling untrusted data in the specific output context, such as HTML body, attribute, JavaScript, CSS, or URL contexts. The second payload shows the defense can be bypassed, so the application is not secure against XSS.