A municipal filter strips semicolon characters from PDF-job inputs but still shells out to build the command. What is the correct conceptual judgment?
Select an answer to reveal the explanation.
Short Explanation
Banning one punctuation mark is like locking one window and leaving the rest open. Metacharacter blacklists crack under alternates and encoding. The real fix is not playing Whac-A-Mole — use safe APIs and tight allowlists.
Full Explanation
Blacklist filters for metacharacters are brittle; prefer safer APIs and allowlists over character denylists. A municipal filter that strips semicolons yet still shells out to build a PDF command remains conceptually weak because other separators, encodings, or injection styles may survive—and the architecture still treats untrusted input as command text. Safer designs avoid the shell.
Blocking one separator does not prove command injection is impossible forever. Open-source PDF libraries do not make shelling out always safe. Command-injection defenses are needed on Unix and Windows civic hosts alike.
Exam caveat: character blacklists are a recurring false comfort in CPTS-style questions; architectural removal of shell concatenation is the durable fix. Report residual risk if denylists remain the only control.
Operational check: remove shell invocation from the PDF job path, pass arguments safely, add allowlisted job parameters, and retest that previously interesting metacharacter cases no longer influence process execution. When refactoring the municipal PDF job, delete the denylist entirely once the shell path is gone so operators are not comforted by obsolete filters. Delete obsolete metacharacter filters after the municipal shell path is removed to avoid false confidence.