SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question
A report generator accepts a user-supplied report name and then passes it into a shell command to convert a file. During testing, a malicious value causes the server to run an unexpected system command. Which two changes best mitigate this issue while keeping the feature usable? Select two.
⚠ Common exam trap
Candidates often choose HTML encoding (Option C) thinking it sanitizes all injection types, but HTML encoding only prevents XSS, not command injection, which requires shell-specific escaping or, better, avoiding shell invocation altogether.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Replace shell command concatenation with a parameterized API or safe library call.
Replacing shell command concatenation with a parameterized API or safe library call prevents command injection by ensuring user input is treated as data, not executable code. This is the most effective mitigation because it eliminates the injection vector entirely, rather than trying to sanitize or validate input that may still be passed to a shell interpreter.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Replace shell command concatenation with a parameterized API or safe library call.
Why this is correct
Avoiding direct shell invocation removes the attacker-controlled command injection path. A safe API or library call passes data as data instead of executable syntax. This is the most effective fix because it eliminates the dangerous pattern rather than trying to filter every possible payload.
- ✓
Apply strict server-side allowlist validation to the report name before processing.
Why this is correct
Allowlisting reduces the input to expected characters or values and blocks metacharacters used in command injection. Validation must happen on the server because client-side checks are easy to bypass. Used with safer command handling, it significantly lowers the risk of abuse.
- ✗
HTML-encode the report name before inserting it into the shell command.
Why it's wrong here
HTML encoding protects web pages from script injection, not operating-system shell interpretation. It does not stop the shell from treating characters like semicolons or pipes as command separators. The control does not address the execution context shown in the scenario.
- ✗
Switch the feature from POST to GET so the values are easier to inspect.
Why it's wrong here
Changing HTTP method does not fix command injection. The vulnerability is in how the server uses the input, not in the request verb. GET may even make sensitive values more visible in logs and history without improving security.
- ✗
Hide the server error messages so attackers cannot see the failure details.
Why it's wrong here
Suppressing error output can reduce information leakage, but it does not stop command execution. The application would still process attacker-controlled shell content if the input is unsafe. This is a helpful hardening measure, not a root-cause fix.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SY0-701 question from scratch — 1,013 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.