312-50 Question 340
Single answer▪ Attack Web App ClientDuring an authorized internal engagement, you are asked to assess whether users of the company’s legacy intranet portal can be compromised through the browser. The portal is only reachable from the corporate network and heavily used by employees with Internet Explorer compatibility mode enabled. You discover a stored cross-site scripting (XSS) flaw in a comments field that is rendered in other users’ browsers without output encoding. The client wants a proof of concept that demonstrates risk without dropping malware or causing instability. Which action is the MOST appropriate to show how an attacker could leverage this client-side web application weakness?
- A
Inject JavaScript that silently sends the victim’s session cookie or anti-CSRF token to a listener you control, demonstrating account compromise risk
- B
Upload a server-side web shell through the comments field to gain command execution on the intranet web server
- C
Use SQL injection against the comments table to dump employee passwords and prove the impact of the XSS issue
- D
Launch a SYN flood against employee workstations after the script executes to show denial-of-service impact
Show answer and explanation
Correct answer: A
Explanation
The key phrase in the scenario is stored XSS rendered in users’ browsers. In CEH terms, attacking the web app client focuses on exploiting client-side trust in the browser context, not immediately compromising the server. The most appropriate proof of concept is one that shows code execution in the victim’s browser and a realistic consequence such as session theft, token theft, or unauthorized actions performed as that user. This aligns with widely accepted guidance from OWASP on Cross Site Scripting, which explains that XSS can be used to hijack sessions, deface content, redirect users, or perform actions on behalf of victims. A controlled demonstration should minimize operational risk and stay within authorization boundaries, so exfiltrating a test token or cookie to an approved listener is a standard, practical way to prove impact without dropping malware or disrupting systems.
- A. Correct.
Correct. Stored XSS is a client-side web application attack that executes in other users’ browsers in the security context of the vulnerable site. A safe proof of concept commonly demonstrates session hijacking risk, token theft, unauthorized actions, or DOM manipulation rather than deploying malware. Exfiltrating a nonproduction test session cookie or anti-CSRF token to an approved listener clearly shows how a browser-based attack on the web app client can lead to account takeover or impersonation.
- B. Incorrect.
Incorrect. A web shell is a server-side compromise technique and does not logically follow from exploiting a stored XSS flaw in a comments field. XSS affects the victim’s browser, not the application server’s operating system. Someone might choose this because both involve web applications, but the attack surface and impact path are different.
- C. Incorrect.
Incorrect. SQL injection is a separate server-side vulnerability and cannot be assumed just because stored XSS exists. This option reflects a common misconception that one web flaw automatically implies another. The scenario specifically asks for the most appropriate demonstration of the client-side weakness discovered, so pivoting to SQL injection would not directly validate the XSS risk.
- D. Incorrect.
Incorrect. A SYN flood is a network-layer denial-of-service attack and is unrelated to demonstrating exploitation of a browser-based XSS condition. Although JavaScript can trigger repeated requests, that would not be an appropriate or controlled proof of concept for the identified vulnerability and could cause instability, which the client explicitly wants to avoid.