CAS-002 · Question #807
Ann is testing the robustness of a marketing website through an intercepting proxy. She has intercepted the following HTTP request: POST /login.aspx HTTP/1.1 Host: comptia.org Content-type…
The correct answer is C. Remove the txtPassword post data and change alreadyLoggedIn from false to true. This question tests the ability to identify a client-side parameter manipulation attack that can bypass server-side authentication logic.
Question
Ann is testing the robustness of a marketing website through an intercepting proxy. She has intercepted the following HTTP request:
POST /login.aspx HTTP/1.1 Host: comptia.org Content-type: text/html txtUsername=ann&txtPassword=ann&alreadyLoggedIn=false&submit=true Which of the following should Ann perform to test whether the website is susceptible to a simple authentication bypass?
Options
- ARemove all of the post data and change the request to /login.aspx from POST to GET
- BAttempt to brute force all usernames and passwords using a password cracker
- CRemove the txtPassword post data and change alreadyLoggedIn from false to true
- DRemove the txtUsername and txtPassword post data and toggle submit from true to false
How the community answered
(64 responses)- A2% (1)
- B5% (3)
- C84% (54)
- D9% (6)
Why each option
This question tests the ability to identify a client-side parameter manipulation attack that can bypass server-side authentication logic.
Changing the request method from POST to GET alters how data is transmitted but does not manipulate any authentication logic or test for parameter-based bypass vulnerabilities.
Brute forcing credentials is a separate attack technique aimed at guessing valid credentials, not exploiting flaws in the authentication decision logic itself.
The alreadyLoggedIn field is a client-controlled value sent in the POST body. If the server trusts this parameter without independent server-side session verification, flipping it to true while removing the password can cause the application to skip its authentication check entirely. This is a classic parameter tampering vulnerability where business logic is enforced on the client rather than the server.
Setting submit to false would likely cause the server to ignore the form submission entirely, which does not test whether the authentication mechanism can be bypassed.
Concept tested: Client-side parameter tampering for authentication bypass
Source: https://owasp.org/www-community/attacks/Web_Parameter_Tampering
Topics
Community Discussion
No community discussion yet for this question.