312-50 Question 313
Single answer▪ Bypass Client-Side ControlsDuring an authorized web application assessment, you test a profile update function that includes an email field. In the browser, the field blocks values longer than 30 characters and only allows characters matching a JavaScript regex. When you intercept the request with a proxy and manually modify the POST body, the server accepts a 120-character value containing characters the page would normally reject, and the application stores it successfully. Which conclusion is MOST accurate?
- A
The application relies on client-side validation for this field, and equivalent server-side validation is missing or insufficient.
- B
The browser's same-origin policy has been bypassed, allowing arbitrary modification of form fields.
- C
The application is protected because the browser prevented invalid input before submission, even if the proxy changed it later.
- D
This behavior proves the application is vulnerable to SQL injection in the email field.
Show answer and explanation
Correct answer: A
Explanation
This scenario tests the candidate's understanding of bypassing client-side controls in a realistic web application assessment. In practice, controls implemented in HTML and JavaScript are easily bypassed using intercepting proxies such as Burp Suite, browser developer tools, curl, or custom scripts. The key CEH takeaway is that client-side validation is useful for user experience, but security decisions must be enforced on the server. This aligns with widely accepted secure development guidance, including OWASP recommendations: input validation must be performed server-side, and client-side validation should be treated as supplemental only. The observed behavior does not automatically imply a more specific issue such as SQL injection; it specifically demonstrates that the application trusts client-side restrictions and fails to enforce equivalent validation on the server.
- A. Correct.
Correct. This is the classic indicator of a client-side control being used as the primary enforcement mechanism. Client-side checks such as HTML attributes, JavaScript regex validation, disabled fields, and input length restrictions can be altered or bypassed by an attacker using developer tools, a proxy, or custom requests. If the server accepts manipulated input that the browser would have blocked, then server-side validation is absent or not enforcing the same business rules.
- B. Incorrect.
Incorrect. Same-origin policy governs how scripts from one origin interact with resources from another origin. Intercepting and modifying your own HTTP request with a testing proxy does not require bypassing same-origin policy. This option confuses browser security boundaries with application input validation weaknesses.
- C. Incorrect.
Incorrect. Client-side validation may improve usability, but it is not a security boundary. Once a request leaves the browser, an attacker can tamper with it. If the server trusts the browser's checks and does not revalidate input, the control is ineffective from a security perspective.
- D. Incorrect.
Incorrect. Accepting overlong or regex-bypassing input does not by itself prove SQL injection. It demonstrates inadequate server-side validation. SQL injection would require evidence that user input is being unsafely incorporated into database queries without proper parameterization or escaping.