A transit rider-account app assessment reviews a debug admin feature under ROE. Which risk surface best indicates possible command-injection exposure?
Select an answer to reveal the explanation.
Short Explanation
If the debug panel can whisper to the OS shell with whatever the user typed, that is command-injection country. Pretty CSS and CDN fluff are not the smoking gun—watch those admin helpers.
Full Explanation
Command-injection exposure appears where application logic passes attacker-influenced input into operating-system command execution. In a transit rider-account app under ROE, admin debug helpers that pass unsanitized input into OS commands are the clearest risk surface: debug traceroute, ping, or shell-out utilities frequently become injection points when input is concatenated into command strings. Identifying that pattern focuses testing where impact is real.
Static CSS themes that never reach a shell are presentation assets, not command sinks. Read-only CDN caching of public marketing pages does not invoke OS process calls with user input. TLS certificate pin lists with no OS process calls address transport trust, not command execution. Those distractors sound technical but do not describe the injection sink.
Exam caveat: command-injection recognition stems point at unsanitized input flowing into OS/shell helpers, especially admin/debug tools—not CSS, CDN, or TLS pin lists. Operational check: inventory admin debug features that shell out, confirm whether input is parameterized or escaped, and treat any unsanitized pass-through as a high-priority command-injection candidate under ROE.