Multiple choice technology security

The application is receiving input from an external source. Which of the following external sources can be considered safe?

  1. Shell environment variables

  2. Data received via encrypted network channels

  3. argv[0] can only have either null or program name

  4. no external input must be trusted

Reveal answer Fill a bubble to check yourself
D Correct answer
Explanation

A. Shell environment variables

Shell environment variables are not considered safe because they can be easily modified by the user. For example, a user could set the PATH environment variable to include a malicious directory, which would allow the application to execute arbitrary code.

B. Data received via encrypted network channels

Data received via encrypted network channels is considered more safe than other sources of external input, but it is still not completely safe. The encryption could be broken, or the data could be intercepted and modified before it is decrypted.

C. argv[0] can only have either null or program name

The argv[0] parameter is the name of the program that is being executed. It is not considered a safe source of input because it can be easily modified by the user. For example, a user could change the argv[0] parameter to a malicious program, which would then be executed instead of the intended program.

D. no external input must be trusted

The correct answer is D. No external input must be trusted, regardless of the source. Even if the input comes from a seemingly safe source, it is always possible that the input has been tampered with. Therefore, it is important to always validate and sanitize all external input before it is processed by the application.

The correct answer is therefore D.

AI explanation

Correct answer: No external input must be trusted.

The core secure-coding principle is that all external input — regardless of its apparent source — should be treated as untrusted and validated/sanitized before use. This is because each of the other options is deceptively "safe-looking" but actually isn't: shell environment variables can be manipulated by an attacker before a program runs; encrypted channels only protect data in transit, they don't guarantee the payload's content is well-formed or benign; and argv[0] is not guaranteed to be null or the true program name — it can be set to arbitrary values by whoever invokes the process (a classic source of confused-deputy/path-based exploits). So the only safe stance is to trust nothing external by default.