A developer has implemented a piece of client-side JavaScript code to sanitize a user's provided input to a web page login screen. The code ensures that only the upper case and lower case letters…

Question

Options

• AThe security administrator is concerned with nonprintable characters being used to gain
• BThe security administrator is concerned with XSS, and the developer should normalize Unicode
• CThe security administrator is concerned with SQL injection, and the developer should implement
• DThe security administrator is concerned that someone may log on as the administrator, and the

• A
  6% (3)
• B
  2% (1)
• C
  81% (42)
• D
  12% (6)

Explanation

The web server log shows the request: pass=pass%20or%201=1, which URL-decodes to pass or 1=1 - a classic SQL injection payload. The attacker bypassed the client-side JavaScript validation entirely (by crafting a direct HTTP request) and injected SQL syntax into the password field. If the server builds SQL queries by concatenating user input, the condition 1=1 always evaluates to true, potentially granting unauthorized access. The JavaScript sanitization only runs in the browser - it provides zero protection against attackers who send requests directly to the server. The fix is server-side input validation and parameterized queries (prepared statements), which separate SQL code from user-supplied data, making injection impossible. Options A and B misidentify the attack type. Option D understates the severity of the issue.

No community discussion yet for this question.