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.

• ✗

  Enabling SSL/TLS

  Why it's wrong here

  SSL/TLS (Transport Layer Security) encrypts communication between the client and server, protecting data confidentiality and integrity during transit. While crucial for overall security, it does not prevent Cross-Site Request Forgery (CSRF) because CSRF attacks leverage the victim's authenticated session and the browser's automatic inclusion of cookies, regardless of whether the connection is encrypted. The malicious request, even if sent over HTTPS, is still processed by the server as a legitimate request from the authenticated user.

• ✗

  Using HTTP GET for all form submissions

  Why it's wrong here

  Using HTTP GET for all form submissions significantly increases vulnerability to CSRF attacks, rather than preventing them. GET requests can be easily embedded in image tags (<img>), script tags (<script>), or simple hyperlinks (<a>) on a malicious third-party site, triggering the action when the victim's browser loads the page. While HTTP POST is generally preferred for state-changing operations due to its idempotence and less visible parameters, neither method inherently prevents CSRF without additional security mechanisms like tokens.

• ✓

  Implementing CSRF tokens

  Why this is correct

  Implementing CSRF tokens is the standard and most effective defense against Cross-Site Request Forgery attacks. A unique, unpredictable token is generated by the server for each user session and embedded within forms or request headers. The server then validates this token upon receiving a request; if the token is missing or incorrect, the request is rejected, preventing an attacker from forging requests that originate from a different site without knowledge of the valid token. This mechanism ensures that only requests originating from the legitimate application are processed.

• ✗

  Using input validation

  Why it's wrong here

  Input validation focuses on ensuring that data submitted by a user conforms to expected formats and types, preventing issues like SQL injection or Cross-Site Scripting (XSS) by sanitizing or rejecting malicious input. However, it does not address the fundamental problem of Cross-Site Request Forgery (CSRF), which involves an authenticated user unknowingly sending a legitimate-looking request initiated by an attacker from a different origin. The request itself, even if it contains valid input, is still unauthorized in its origin.

Go deeper

Related to this question