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.

• ✓

  Setting SameSite cookies to Lax or Strict

  Why this is correct

  Setting SameSite cookies to Lax or Strict significantly mitigates CSRF by controlling when cookies are sent with cross-site requests. Lax mode sends cookies only with top-level navigations (typically GET requests) and not with cross-site POST requests or iframes, preventing most forged state-changing requests. Strict mode offers even stronger protection by never sending cookies with any cross-site requests, ensuring the session cookie is only included for same-site origins.

• ✗

  Input validation

  Why it's wrong here

  Input validation is ineffective against CSRF because it focuses on ensuring the data submitted to the server adheres to expected formats and constraints, not on verifying the request's origin or user intent. A CSRF attack crafts a legitimate-looking request containing valid data parameters, which would pass typical input validation checks. The core issue in CSRF is the browser automatically attaching the user's session cookie to an unintended request, a problem input validation cannot address.

• ✓

  Implementing CSRF tokens in forms

  Why this is correct

  Implementing CSRF tokens is a highly effective mitigation where a unique, unpredictable, and cryptographically secure token is generated by the server for each user session. This token is embedded within hidden fields of forms or as a custom request header. Upon submission, the server validates the received token against the one stored in the user's session, ensuring the request originated from a legitimate, user-initiated action and not a forged cross-site request.

• ✗

  Using CAPTCHA

  Why it's wrong here

  While CAPTCHA helps distinguish human users from automated bots, it is not a primary or effective mitigation against CSRF. A CAPTCHA might add a hurdle to an attacker attempting to automate many requests, but it does not prevent a single, targeted CSRF attack where a legitimate, authenticated user's browser is tricked into sending a forged request. The browser will still automatically attach the session cookie, and the CAPTCHA mechanism itself can often be bypassed or is not applied to every sensitive action.

• ✗

  Using HTTPS only

  Why it's wrong here

  Using HTTPS only encrypts the communication channel between the client and server, protecting against eavesdropping and Man-in-the-Middle attacks, but it does not prevent CSRF. CSRF exploits the browser's inherent behavior of automatically sending session cookies with requests to a trusted domain when the user is authenticated. The forged request, even if sent over a secure HTTPS connection, still appears to originate from the legitimate user's browser with their valid session cookie, making HTTPS irrelevant to the CSRF vulnerability itself.

Go deeper

Related to this question