SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question
Exhibit
Application log excerpt: 15:08:02 POST /tools/pingHost host=10.0.0.15 15:08:02 Application executed: /bin/sh -c "ping -c 1 10.0.0.15" 15:09:11 POST /tools/pingHost host=10.0.0.15;curl%20http://198.51.100.55/s 15:09:11 Application executed: /bin/sh -c "ping -c 1 10.0.0.15;curl http://198.51.100.55/s" 15:09:12 Outbound HTTPS session established to 198.51.100.55
Based on the exhibit, what is the BEST remediation for the application flaw shown?
A user-controlled parameter is being passed to a shell command on the server. The application is intended to test connectivity to approved internal hosts only.
⚠ Common exam trap
It's easy for candidates to confuse command injection with cross-site scripting (XSS) and choose HTML encoding (Option A), or they mistakenly think authentication (Option D) or timeout adjustments (Option C) can fix a code-level injection vulnerability.
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 the shell call with a safe library function and strictly allowlist approved host values.
The application flaw is command injection: a user-controlled parameter is passed directly to a shell command (e.g., `ping`). The best remediation is to replace the shell call with a safe library function (e.g., `InetAddress.isReachable()` in Java or a dedicated ICMP library) and strictly allowlist approved internal host values, eliminating the possibility of injecting arbitrary commands like `; rm -rf /`.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Keep the current shell command, but add HTML encoding to the response page.
Why it's wrong here
HTML encoding is a client-side output control that only prevents the browser from interpreting injected markup as active content, such as in stored or reflected XSS. It does nothing to stop the web server from passing the user-supplied parameter into the shell, meaning the injected malicious command has already executed on the server before any response is rendered. This solution treats the symptom in the browser while leaving the root cause—unvalidated input reaching an OS command—completely unpatched.
- ✓
Replace the shell call with a safe library function and strictly allowlist approved host values.
Why this is correct
Substituting the raw shell call with a safe library function, such as using subprocess.run() with a list argument and shell=False, ensures the input is passed as data rather than interpreted by a shell. An allowlist of approved host values then blocks any string that does not match an expected pattern, so an attacker cannot inject metacharacters like ';', '|', or '&&' into the command. This directly eliminates both the injection vector and the attack surface by combining parameterized execution with strict input validation.
- ✗
Increase the web server timeout so the ping utility has more time to complete.
Why it's wrong here
Extending the web server timeout merely gives the ping utility more time to finish a normal request; it does not prevent an attacker from appending additional OS commands after the ping argument. Worse, a longer timeout can actually help an attacker run more time-consuming payloads, such as a long-running or resource-exhausting command, making the denial-of-service aspect more severe. The remediation ignores the core defect, which is unsafe handling of untrusted input that allows arbitrary command execution.
- ✗
Require users to authenticate before they can access the page.
Why it's wrong here
Requiring authentication may reduce the number of people who can reach the vulnerable page, but any authenticated user—or an attacker who compromises a valid account—can still exploit the same command injection to execute arbitrary code. Many exposed pages are intentionally public, and identification does not validate the input or change how the shell command is constructed. The underlying vulnerable code remains live, so the flaw is only hidden behind a weak perimeter, not actually fixed.
Go deeper
Related to this question
About these practice questions
This SY0-701 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.