Exploiting XSS with HTTPOnly Cookies via HTML Encoding

Hacking Web Applications

Answer Correct answer: D — Create a sophisticated XSS payload that leverages HTML encoding to bypass the input sanitization, and then use it to redirect users to a malicious site where their cookies can be captured.

As part of a penetration testing team, you've discovered a web application vulnerable to Cross-Site Scripting (XSS). The application sanitizes inputs against standard XSS payloads but fails to filter out HTML-encoded characters. On further analysis, you've noticed that the web application uses cookies to track session IDs. You decide to exploit the XSS vulnerability to steal users' session cookies. However, the application implements HTTPOnly cookies, complicating your original plan. Which of the following would be the most viable strategy for a successful attack?

Build an XSS payload using HTML encoding and use it to exploit the server-side code, potentially disabling the HTTPOnly flag on cookies.
Develop a browser exploit to bypass the HTTPOnly restriction, then use a HTML-encoded XSS payload to retrieve the cookies.
Utilize an HTML-encoded XSS payload to trigger a buffer overflow attack, forcing the server to reveal the HTTPOnly cookies.
Create a sophisticated XSS payload that leverages HTML encoding to bypass the input sanitization, and then use it to redirect users to a malicious site where their cookies can be captured. Correct Answer

Community Votes

100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The core trap is assuming HTTPOnly cookies can be stolen directly; the viable strategy involves leveraging encoding bypasses for alternative data exfiltration methods like redirection.

This question examines how to exploit Cross-Site Scripting (XSS) when HTTPOnly flags prevent direct cookie access, focusing on input sanitization bypasses.

Learners often select options suggesting technical impossibilities, such as disabling server-side flags or triggering buffer overflows via client-side XSS, due to a misunderstanding of browser security boundaries.

Community Discussion (3 comments)

NikoTomas 👍 1 Selected: D

Answer: D I’m choosing D) because other answers are unrealistic and useless but D) also won’t work as presented in the answer because when user is redirected to the malicious site, then only cookies belonging to the TARGET SITE are sent with the request (if some exists in the browser) but NOT cookies belonging to the SOURCE SITE which we are hacking. So attacker won't get the cookies in question with HttpOnly flag. Anyway, the malicious site can be useful for another hacks then...

pindinga1 👍 2 Selected: D

The correct answer is: D. Create a sophisticated XSS payload that leverages HTML encoding to bypass the input sanitization, and then use it to redirect users to a malicious site where their cookies can be captured. Explanation: The scenario involves a web application vulnerable to Cross-Site Scripting (XSS) that sanitizes inputs against standard XSS payloads but fails to filter out HTML-encoded characters. Additionally, the application uses HTTPOnly cookies, which prevent client-side scripts (like JavaScript) from accessing the cookies directly. Here's why option D is the most viable strategy:

MHafizC 👍 2 Selected: D

HTML Encoding to Bypass Input Sanitization: Since the application fails to filter out HTML-encoded characters, you can craft an XSS payload that uses HTML encoding to bypass the input sanitization. Redirecting Users to a Malicious Site: By redirecting users to a malicious site, you can capture their session cookies through other means, such as social engineering or exploiting vulnerabilities on the malicious site. This approach circumvents the HTTPOnly restriction, as the cookies are not directly accessed by the script but are instead sent to the malicious site.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Option D is the most viable strategy because it acknowledges the limitation imposed by the HTTPOnly flag while exploiting the application's specific weakness: the failure to filter HTML-encoded characters. By crafting an XSS payload using HTML encoding, the attacker bypasses input sanitization. While the prompt states the goal is to steal session cookies, and HTTPOnly prevents direct JavaScript access to them, redirecting users to a malicious site is a standard step in complex attack chains (such as capturing other sensitive data or setting up further phishing). Among the choices, this is the only technically plausible action that utilizes the identified vulnerability (HTML encoding bypass).

Why the Other Options Are Wrong

Options A, B, and C describe technically impossible actions for a standard web application penetration test. Option A suggests disabling the HTTPOnly flag via client-side code, which is not possible as HTTPOnly is a server-set attribute enforced by the browser. Option B proposes a "browser exploit" to bypass HTTPOnly, which is outside the scope of a standard XSS exploitation technique and implies a zero-day vulnerability in the browser itself. Option C suggests triggering a buffer overflow on the server via client-side XSS, which is architecturally incorrect as XSS executes in the client's browser context, not on the server.

Community Comment Notes

The community overwhelmingly voted for D, recognizing that the other options are nonsensical. However, one commenter (NikoTomas) correctly pointed out a nuance: simply redirecting a user to a malicious site does not automatically send the target site's cookies to the attacker's domain due to Same-Origin Policy. This highlights that while D is the 'best' answer among flawed options, the explanation provided in the study guide might oversimplify the actual mechanics of cookie theft in this specific scenario.

Exam Strategy

When faced with XSS questions involving HTTPOnly cookies, eliminate any option that claims to read the cookie value directly via JavaScript or modify server-side attributes. Look for answers that focus on bypassing input validation (like encoding tricks) and redirecting or interacting with the user, even if the final outcome description is slightly imperfect.

Frequently Asked Questions

Can XSS read HTTPOnly cookies?

No, HTTPOnly cookies cannot be accessed via JavaScript (document.cookie). Attackers must rely on other vectors or social engineering.

Why is HTML encoding used here?

It bypasses input sanitizers that only check for raw script tags but fail to decode and evaluate HTML entities before rendering.

More 312-50v13 FAQ →

Related Analysis

← Back to 312-50v13 Study Guide