Chapter 8 — Programming II

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 A small service"]
  N2["8.2 Testing access rules"]
  N3["8.3 Logging usefully"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 A small service"]
  N2["8.2 Testing access rules"]
  N3["8.3 Logging usefully"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 A small service]
    |
    v
[8.2 Testing access rules]
    |
    v
[8.3 Logging usefully]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) build a small web service with authentication and authorisation; (2) write tests for access-control rules; (3) log security-relevant events usefully.

8.1 A small service

In Programming II Lucas builds a synthetic stock-query service for store staff using Python's standard library HTTP server for learning purposes. Staff log in, then query stock levels; managers can also adjust stock. He separates authentication, which establishes who the user is, from authorisation, which decides what that user may do. Each request checks both. He learns that mixing them causes bugs, such as checking only that a user is logged in and forgetting to check whether that user is a manager before allowing an adjustment.

8.2 Testing access rules

Lucas writes tests for every combination of role and action: staff can query, staff cannot adjust, managers can do both, anonymous users can do neither. He also tests edge cases, such as a manager from one store adjusting another store's stock, which the rules forbid. A test fails: the service checks the manager role but not the store. He fixes the check and the test passes. Testing access rules as a matrix makes missing checks visible, and these tests later protect the rule when someone modifies the code.

8.3 Logging usefully

The service logs logins, failed logins, stock adjustments and authorisation failures with user, time, action and outcome, but never passwords or session tokens. Lucas learns that logs serve investigations, so each entry must answer who did what, when and with what result. He also learns to avoid logging excessive personal data. Hannah reviews his log design and asks for a correlation identifier for each request, so that events across services can be linked during an incident. Useful logging is designed with its future readers in mind.

Worked example

Lucas builds a stock service separating authentication from authorisation, finds a missing store check through a role-action test matrix and designs logs with correlation identifiers.

Synthetic case. The service, roles and stores are synthetic.

Errors and limits

Standard-library servers are for learning; production uses maintained frameworks. Test matrices grow quickly with roles and resources.

Exercises

• EX022 — AuthN versus AuthZ. What is the difference between authentication and authorisation?
  Show marking criteria

  Rubric: 3 = authentication establishes identity; authorisation decides permitted actions;; 2 = both;; 1 = same;; 0 = none.
• EX023 — Failed test. Which test failed and why?
  Show marking criteria

  Rubric: 3 = manager adjusting another store's stock; store not checked;; 2 = named;; 1 = vague;; 0 = none.
• EX024 — Never logged. What must never appear in logs?
  Show marking criteria

  Rubric: 3 = passwords or session tokens;; 2 = both;; 1 = usernames;; 0 = none.

Synthesis

Secure services separate identity from permission, test every rule combination and log what investigators will need.

Continue studying — chapter 08 of 40

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →