An attacker can embed in a web page a malicious script that does not generate any warning but captures session tokens in the background and sends them to the attacker.

An attacker can embed in a web page a malicious script that does not generate any warning but captures session tokens in the background and sends them to the attacker.

• A. Trojans
• B. CSRF Attack
• C. Malicious JavaScript codes
• D. Session Hijacking

Answer: (C)

The main idea is that code running in the user's browser can quietly grab session data from the page and send it to an attacker. A web page that includes a malicious script can access tokens stored in the browser (such as in non-HttpOnly cookies or in localStorage) and exfiltrate them without showing any warning to the user. That’s why this scenario fits Malicious JavaScript codes: the attack relies on client-side scripting embedded in the page to covertly harvest credentials. CSRF, in contrast, leverages an authenticated user’s session to perform actions on another site, not to steal the token itself. Session hijacking is the result of token theft or takeover but the described mechanism specifically points to the malicious script in the page stealing tokens. Defenses include marking tokens as HttpOnly so scripts can’t read them, using Secure and SameSite cookies, applying a strict Content Security Policy to block untrusted scripts, and avoiding storing sensitive tokens in localStorage. Also consider short token lifetimes and server-side protections to detect unusual exfiltration attempts.

The main idea is that code running in the user's browser can quietly grab session data from the page and send it to an attacker. A web page that includes a malicious script can access tokens stored in the browser (such as in non-HttpOnly cookies or in localStorage) and exfiltrate them without showing any warning to the user. That’s why this scenario fits Malicious JavaScript codes: the attack relies on client-side scripting embedded in the page to covertly harvest credentials.

CSRF, in contrast, leverages an authenticated user’s session to perform actions on another site, not to steal the token itself. Session hijacking is the result of token theft or takeover but the described mechanism specifically points to the malicious script in the page stealing tokens.

Defenses include marking tokens as HttpOnly so scripts can’t read them, using Secure and SameSite cookies, applying a strict Content Security Policy to block untrusted scripts, and avoiding storing sensitive tokens in localStorage. Also consider short token lifetimes and server-side protections to detect unusual exfiltration attempts.