CEH Web Application and Injection Attacks Practice Question

During a web application penetration test, a tester uses Burp Suite's Repeater tool to manually manipulate a request and observe the response. After sending the same request multiple times, the application returns a 302 redirect pointing to a login page. What is the MOST likely cause?

⚠ Common exam trap

CEH often tests whether candidates can distinguish authentication/session-expiry responses (302 to login) from authorization failures (403), rate limiting (429), and CSRF rejections — the trap is picking a security control that sounds plausible but returns a different status code.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

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

A 302 redirect to the login page is the classic server-side signal that the session cookie presented in the request is no longer valid — either it expired, was invalidated server-side, or the session store lost the record. Burp Repeater replays the exact same request with the same session token, so once that token ages out or is rotated, every subsequent replay gets bounced to authentication. This is expected behavior, not a security control firing.

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

CEH Web Application and Injection Attacks Practice Question

Why each option matters

Option-by-option breakdown

Related to this question