CEH Web Application and Injection Attacks Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  SameSite=Strict

  Why it's wrong here

  SameSite=Strict is a cookie attribute designed to mitigate CSRF by preventing the browser from sending the cookie with cross-site requests. This means if a user is logged into example.com and then visits malicious.com, any request initiated by malicious.com to example.com will not include the session cookie. While highly effective against many CSRF scenarios, it can sometimes break legitimate cross-site functionality and doesn't protect against same-site request forgery or if the state-changing action doesn't strictly require the session cookie.

• ✗

  HTTPOnly flag

  Why it's wrong here

  The HTTPOnly flag prevents client-side scripts, such as JavaScript, from accessing the cookie via document.cookie. Its primary purpose is to mitigate the impact of Cross-Site Scripting (XSS) attacks, where an attacker might inject malicious script to steal session cookies. However, HTTPOnly does not prevent the browser from automatically sending the cookie with requests to the server, which is the fundamental mechanism exploited by CSRF attacks. Therefore, it offers no direct protection against CSRF.

• ✗

  Secure flag

  Why it's wrong here

  The Secure flag ensures that a cookie is only sent by the browser over encrypted HTTPS connections, never over unencrypted HTTP. This protects the cookie from passive network eavesdropping and man-in-the-middle attacks that attempt to steal session information. While essential for overall application security and maintaining session integrity, the Secure flag does not prevent a malicious site from tricking a user's browser into sending an authenticated request to a legitimate HTTPS endpoint. The browser will still include the Secure cookie if the destination is HTTPS, regardless of the request's origin.

• ✓

  CSRF token

  Why this is correct

  A CSRF token is a unique, unpredictable, and secret value generated by the server and included with every state-changing request, typically embedded in hidden form fields or request headers. The server validates this token upon receiving the request, ensuring it matches the token associated with the user's session. Since a malicious attacker operating from a different origin cannot obtain or guess this secret token, they cannot craft a valid forged request that the server would accept, thereby effectively preventing CSRF attacks.

Go deeper

Related to this question