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.

• ✗

  The server is rate-limiting the requests

  Why it's wrong here

  Rate-limiting mechanisms are designed to prevent resource abuse by restricting the number of requests a client can make within a specific timeframe. When triggered, servers typically respond with a 429 Too Many Requests HTTP status code, sometimes accompanied by a Retry-After header. A 302 Found redirect to a login page does not align with standard rate-limiting responses, as it suggests a session or authentication problem rather than an overload prevention measure.

• ✗

  A cross-site request forgery (CSRF) token mismatch occurred

  Why it's wrong here

  A CSRF token mismatch occurs when the server receives a request with an invalid or missing anti-CSRF token, indicating a potential forgery attempt or an expired form. This security control is designed to protect against unauthorized state-changing actions. Typically, such a failure results in a 400 Bad Request, a 403 Forbidden, or a custom error page, explicitly rejecting the malicious request. A 302 redirect to a login page is not the standard response for a CSRF token validation failure, as it doesn't directly address the integrity of the specific request.

• ✓

  The session token has expired and the user must re-authenticate

  Why this is correct

  When a session token expires, the server invalidates the associated user session, meaning it no longer recognizes the client as authenticated. This is a common security measure to limit the window of opportunity for session hijacking. Upon receiving a request with an expired or invalid session token, the application's security logic often redirects the user to the login page (HTTP 302 Found) to prompt re-authentication and establish a new, valid session. This behavior directly aligns with the observed 302 redirect.

• ✗

  The server detected the use of a proxy and blocked the request

  Why it's wrong here

  Servers implementing proxy detection mechanisms aim to identify and block requests originating from known proxies, VPNs, or Tor exit nodes, often for fraud prevention or geographic restrictions. When such detection occurs and blocking is enforced, the typical response is a 403 Forbidden status code, a direct connection reset, or a custom block page. A 302 redirect to a login page does not signify a proxy-based block; instead, it points to an issue with the user's authentication state rather than the origin of the request.

Go deeper

Related to this question