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 the Secure flag on cookies

  Why it's wrong here

  The Secure flag ensures that a cookie is only transmitted over encrypted HTTPS connections, preventing man-in-the-middle attacks from intercepting it. However, it does not prevent Cross-Site Request Forgery (CSRF) because the legitimate user's browser will still automatically send the authenticated session cookie with a forged request to the vulnerable site, even if that request is made over HTTPS. The attack leverages the browser's trust in the user's session, not the transport layer's security.

• ✗

  Using input validation to block special characters

  Why it's wrong here

  Input validation is a crucial security measure designed to sanitize or reject user-supplied data that contains potentially malicious characters or patterns. This defense primarily mitigates injection attacks like SQL Injection or Cross-Site Scripting (XSS) by preventing an attacker from manipulating server-side queries or client-side scripts. However, CSRF attacks do not rely on malformed input; instead, they trick an authenticated user's browser into sending legitimate, but unauthorized, requests to a vulnerable web application, bypassing the need for input manipulation.

• ✓

  Using anti-CSRF tokens that are validated on the server

  Why this is correct

  Anti-CSRF tokens are unique, unpredictable, and secret values generated by the server and embedded into forms or request headers. When a user submits a form or makes an AJAX request, the browser sends this token along with the request. The server then validates this token against the one stored in the user's session. If the tokens do not match, the request is rejected, effectively ensuring that the request originated from the legitimate application and not from a malicious third-party site.

• ✓

  Implementing SameSite cookie attribute (Lax or Strict)

  Why this is correct

  The SameSite cookie attribute, particularly when set to 'Lax' or 'Strict', instructs the browser to restrict when cookies are sent with cross-site requests. With 'Strict', cookies are only sent for same-site requests, completely preventing cross-site requests from including them. 'Lax' allows cookies for top-level navigations (e.g., clicking a link) but blocks them for other cross-site requests like POST forms or iframes, significantly mitigating CSRF by preventing the automatic inclusion of session cookies in forged requests.

• ✗

  Enabling the HttpOnly flag on session cookies

  Why it's wrong here

  The HttpOnly flag prevents client-side scripts, such as JavaScript, from accessing a cookie. This is a crucial defense against Cross-Site Scripting (XSS) attacks, as it stops an attacker from stealing session cookies via injected scripts. However, HttpOnly does not protect against CSRF because the browser will still automatically include the HttpOnly-flagged session cookie in any request made to the domain it belongs to, regardless of whether the request was initiated by the legitimate site or a malicious one.

Go deeper

Related to this question