Chapter 4 — Programming I

Chapter 4 — Programming I

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 First scripts"]
  N2["4.2 Untrusted input"]
  N3["4.4 Reading code critically"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 First scripts"]
  N2["4.2 Untrusted input"]
  N3["4.4 Reading code critically"]
  N0 --> N1 --> N2 --> N3 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 First scripts]
    |
    v
[4.2 Untrusted input]
    |
    v
[4.4 Reading code critically]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) write simple Python to process security data; (2) validate untrusted input; (3) handle errors without hiding them.

4.1 First scripts

Lindiwe writes her first Python scripts on synthetic Saltmarsh data. One reads a list of user accounts and counts those with no login in ninety days, which are candidates for disabling. She uses only the standard library, so the script runs on any analyst's machine without installing packages. Prof. Hale asks her to print counts with clear labels, because a security report that reads 37 with no context will be misunderstood by the managers who receive it. The script finds thirty-seven inactive accounts in the synthetic file.

4.2 Untrusted input

Input from outside a program cannot be trusted. Lindiwe writes a function that accepts a depot code typed by a user and checks it against the twelve valid codes before using it in a file path. Without this check, an input such as dot-dot-slash sequences could make the program read files outside its folder. She learns that validating input against an allow list, rather than trying to block known bad patterns, is the safer default. She tests the function with ten deliberately malformed codes.

4.3 Errors and logging

Programs fail, and the way they fail matters. Lindiwe's first script stopped silently when a line in the account file was malformed. She rewrites it to log the line number and reason, skip the bad line and report the count of skipped lines at the end. Prof. Hale explains that silent failures are dangerous in security tooling, because a scan that quietly skips half its targets still produces a reassuring report. In the synthetic file, her new version skips three malformed lines and reports them by number, so the data owner can correct the source records.

4.4 Reading code critically

Lindiwe reads a short script a colleague wrote to reset passwords. It builds a shell command by joining strings that include the username. She recognises that a username containing a semicolon could inject a second command. She suggests passing arguments as a list to the subprocess module instead, so no shell interprets them. Prof. Hale says reviewing others' code for such patterns is one of the most valuable habits an engineer can build early. Her colleague agrees, updates the script and asks her to review his next one.

Worked example

Lindiwe writes standard-library scripts with labelled output, validates depot codes against an allow list, logs skipped lines and spots a command injection risk.

Synthetic case. Scripts and data are synthetic.

Errors and limits

Blocking known bad input is weaker than allowing only known good input.

Exercises

• EX010 — Inactive accounts. What does the first script count? Rubric: 3 = accounts with no login in ninety days;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX011 — Allow list. How is the depot code validated? Rubric: 3 = against the twelve valid codes;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX012 — Injection fix. How should the reset script call commands? Rubric: 3 = pass arguments as a list;; 2 = partly correct;; 1 = vague;; 0 = none.

Continue studying — lesson 04 (chapter 04 of 50)

← Chapter 03 · Course chapter index · Chapter 05 →

Continue to the next authored lesson.