312-50 Question 314
Single answer▪ Bypass Client-Side ControlsDuring an authorized web application assessment, you encounter an account update page that uses JavaScript to disable the Submit button unless the phone number matches a specific pattern and the hidden field role=user remains unchanged. The application also disables browser paste in the input field. You need to verify whether these restrictions are only enforced on the client side or also validated by the server. What is the MOST appropriate next step?
- A
Intercept the request with a proxy, modify the phone number and hidden role parameter, then forward the request to observe whether the server accepts or rejects the tampered values
- B
Disable JavaScript in the browser and conclude that any fields that become editable indicate a confirmed server-side validation bypass
- C
Use a vulnerability scanner to identify all JavaScript functions and assume any client-side checks it finds are exploitable
- D
View the page source to identify the regular expression used for phone validation and report it as a vulnerability without sending a modified request
Show answer and explanation
Correct answer: A
Explanation
Bypassing client-side controls means demonstrating that browser-enforced restrictions such as disabled fields, hidden parameters, JavaScript validation, HTML5 attributes, or paste blocking can be circumvented and that the server fails to enforce equivalent checks. The most reliable approach is to intercept the HTTP request and tamper with parameters directly. This aligns with OWASP guidance that client-side controls must never be trusted as a security boundary and that all security-relevant validation and authorization decisions must be performed server-side. In this scenario, altering both the phone number and the hidden role parameter tests two common issues: input validation weaknesses and parameter tampering/privilege manipulation. The vulnerability is only confirmed if the server accepts unauthorized or malformed values instead of rejecting them.
- A. Correct.
Correct. The proper way to test whether a control is only client-side is to intercept and modify the HTTP request before it reaches the server. Tools such as Burp Suite or OWASP ZAP allow the tester to alter hidden fields, disabled parameters, and input values regardless of browser-side restrictions like JavaScript validation or paste blocking. If the server accepts the tampered values, that demonstrates missing or insufficient server-side validation.
- B. Incorrect.
Incorrect. Disabling JavaScript can help reveal whether the UI depends on client-side controls, but it does not prove a server-side bypass by itself. The key question is how the server processes the manipulated request. A field becoming editable in the browser is only an indicator that client-side controls exist, not evidence that the backend will accept invalid or unauthorized data.
- C. Incorrect.
Incorrect. A scanner may identify scripts or input-validation logic, but it cannot justify assuming exploitability without validation. Client-side checks are common and not inherently vulnerabilities if equivalent server-side validation exists. CEH-style testing emphasizes confirming impact through controlled request manipulation rather than making assumptions from code discovery alone.
- D. Incorrect.
Incorrect. Reviewing source code can reveal hidden fields, regex patterns, or JavaScript checks, but source inspection alone is insufficient to establish a vulnerability. Many applications expose client-side validation logic for usability while still enforcing robust server-side controls. A finding should be based on actual backend behavior observed after sending modified input.