Which vulnerability arises when untrusted input is embedded in code or queries?

Which vulnerability arises when untrusted input is embedded in code or queries?

• A. Insufficient input validation
• B. Phishing
• C. Pharming
• D. Injection

Answer: (C)

The main concept is how injection vulnerabilities arise. Injection happens when untrusted input is treated as part of code or as a command, so the interpreter or database executes something that the attacker crafted. When an application builds a query or a command by concatenating user input, the input can alter the structure of that query or command instead of just supplying data. For example, in a login or data-retrieval query, if the code constructs a statement by placing user input directly into the query string, an attacker can supply input that changes the logic of the query (such as bypassing authentication or extracting data). That’s injection in action. Because the vulnerability specifically involves injecting malicious input into code or queries, it’s distinct from phishing (a social engineering attack to steal credentials) or pharming (redirecting users to a malicious site). It’s also more precise than a general “insufficient input validation,” since the issue arises from combining untrusted input with executable code or queries, not just from lax checks alone. The key remedy is to separate code from data, typically using parameterized queries/prepared statements, input validation and escaping, and proper least-privilege database access to prevent the injected input from altering behavior.

The main concept is how injection vulnerabilities arise. Injection happens when untrusted input is treated as part of code or as a command, so the interpreter or database executes something that the attacker crafted. When an application builds a query or a command by concatenating user input, the input can alter the structure of that query or command instead of just supplying data. For example, in a login or data-retrieval query, if the code constructs a statement by placing user input directly into the query string, an attacker can supply input that changes the logic of the query (such as bypassing authentication or extracting data). That’s injection in action.

Because the vulnerability specifically involves injecting malicious input into code or queries, it’s distinct from phishing (a social engineering attack to steal credentials) or pharming (redirecting users to a malicious site). It’s also more precise than a general “insufficient input validation,” since the issue arises from combining untrusted input with executable code or queries, not just from lax checks alone. The key remedy is to separate code from data, typically using parameterized queries/prepared statements, input validation and escaping, and proper least-privilege database access to prevent the injected input from altering behavior.