Command injection

02A list does not invite a parser

In the demonstration, printf is the program and %s is its fixed format: print the next argument as text. The value memo-card is a separate item. check=True asks Python to report a nonzero exit status as an error; shell=False keeps a shell from parsing a command line. The result shown is a prediction, not a fresh execution.

The boundary is caller data entering an instruction parser. Avoiding shell parsing addresses that boundary but does not make every program or argument safe. A program may interpret an argument as an option or perform an unwanted action itself. Windows batch files also have shell-handling differences; this card does not establish their behavior.

1subprocess.run(["printf", "%s", "memo-card"], check=True, shell=False)
2Program: printf
3Fixed format: %s
4Value: memo-card
5Predicted output: memo-card

03Read the safe call

Read the evidence before comparing your reasoning with the activity rubric. Do not run the file.

Original comparison. The shell form is a description, not a program.

Safe pattern, also saved as safe-print.py:
  subprocess.run(["printf", "%s", "club-note"], check=True, shell=False)
  The program name is printf.
  The next item is the format.
  The last item is the value club-note, one argument.
  shell stays false, so this call does not start a shell parser.

Shell form, not saved as a program and not to be typed:
  one string would hold the program and the value together
  a shell would parse that string as a command line
  characters that are syntax to that shell would not stay plain data

Predicted result of the safe call, not observed:
  the process writes club-note and nothing else

"""Fixed program and separate arguments. Authoring did not run this file.

A later run, if separately authorized, may use only the value below.
Do not replace the list with a shell string.
"""
import subprocess

value = "club-note"
subprocess.run(["printf", "%s", value], check=True, shell=False)

1. Count the items in the list passed to run. Write the program name and the value.
2. Read the shell argument on that call.
3. Check: the value club-note is one list item, and the call does not start a shell parser. The predicted write is club-note and nothing else. That write was not observed.
4. Stop. Do not replace the list with a shell string.

04Optional challenge

Explain why a friendlier error page leaves the shell boundary where it was. The rubric is: the page is output, and the parser decision is the call shape. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

value = "field-card"
subprocess.run(["printf", "%s", value], check=True, shell=False)
The supplied model treats printf as a fixed native program.

P: fixed program and separate list arguments, shell=False.
Q: combined command string passed with shell=True.
R: fixed program and separate list arguments, shell=False, caller value begins with a dash.
No call is executed. Avoiding a shell does not decide whether a program accepts an argument safely.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: name every direct-call component; state whether a shell parser is requested; distinguish shell syntax from program argument meaning; preserve fixed program and separate data arguments.