◇ OpenCyber Academy
Bachelor's · Chapter 2 · English

Chapter 2 — Computing systems

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 2 — Computing systems

Lesson map

Lesson 02 published. Map, example, EX004.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 The parts"]
  N2["2.2 Following a request"]
  N3["2.3 Third-party code"]
  N4["2.4 Build and deploy"]
  N5["2.5 Responsibilities"]
  N6["2.6 Shared responsibility"]
  N7["Inventory"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX004"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 The parts"]
  N2["2.2 Following a request"]
  N3["2.3 Third-party code"]
  N4["2.4 Build and deploy"]
  N5["2.5 Responsibilities"]
  N6["2.6 Shared responsibility"]
  N7["Inventory"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX004"]

[Learning outcomes]
    |
    v
[2.1 The parts]
    |
    v
[2.2 Following a request]
    |
    v
[2.3 Third-party code]
    |
    v
[2.4 Build and deploy]
    |
    v
[2.5 Responsibilities]
    |
    v
[2.6 Shared responsibility]
    |
    v
[Inventory]
    |
    v
[Worked example] --> [Exercise EX004]

Learning outcomes

You will (1) describe the parts of a web application system; (2) trace a request from browser to database; (3) identify where third-party code runs; (4) relate system parts to security responsibilities.

2.1 The parts

CampusEats has a browser front end, a web server running application code, a database, a payment provider and a hosting platform. Its code depends on dozens of open-source packages fetched at build time.

Lena draws these parts as boxes and the connections between them as arrows, labelling each arrow with the data it carries, such as orders, sessions or payment requests. The diagram is small, but it is the first map of where things can go wrong, and every later chapter adds detail to it, from network protocols to the build pipeline and its dependencies.

2.2 Following a request

A student taps "order": the browser sends a request over HTTPS; the server checks the session, validates the order, writes to the database, calls the payment provider and returns a confirmation page. Each step is a place where data could be altered, exposed or lost.

For each step Lena writes down what could fail and which check prevents it. The session check stops strangers placing orders in someone else's name, validation stops impossible orders, and the payment call must not run twice if the student taps again. Lena marks these on her diagram.

2.3 Third-party code

Third-party code runs in three places: packages bundled into the browser code, packages on the server, and services such as payments. A flaw in any of them affects CampusEats even though the society did not write it.

Bundled packages run in every visitor's browser, so a malicious update could reach every student who orders food. Server packages can read the database and secrets. Services hold data CampusEats cannot inspect directly. Lena notes which category each dependency falls into, because the right control differs: pinning and integrity checks for packages, contracts and configuration for services.

2.4 Build and deploy

Code goes from the repository to a build service that installs dependencies, runs tests and creates a deployable bundle. The integrity check that stopped the build in Lena's first week sits at the install step.

If any step fails, nothing is deployed, which is why the hash mismatch stopped the build. Lena adds the build steps to her diagram as a second chain of boxes, from commit to deployed bundle, since an attacker who changes something in that chain changes what runs in production without touching the source code the developers review.

2.5 Responsibilities

The society owns its code and configuration; the hosting platform owns servers; the payment provider owns payments. The university's security office sets policy and helps with reviews.

Lena writes these owners next to each box on her diagram. Where an owner is missing, such as for the build service, which a former student set up and nobody now maintains, she marks it as an open question. The society agrees to name an owner for every part before the next term, and the security office checks the list at its annual review.

2.6 Shared responsibility

When responsibilities overlap or are unclear, gaps appear; Lena lists who owns each part.

A typical gap at CampusEats is the payment token itself: the provider issues it, the society stores it and the hosting platform injects it at runtime, so each assumed one of the others was watching it. The leak showed that nobody was. Lena's list now names the society's treasurer as owner of the token, responsible for rotation, and the hosting platform for protecting it at runtime.

Inventory

Lena starts a simple inventory: every component, who owns it and where it runs.

Worked example

Lena's request trace shows the payment provider calls CampusEats back with a "paid" notification. Nobody had checked how CampusEats knows that message is genuine. Grace marks it for chapter 17, which covers message signatures.

Synthetic case. Systems and flows are synthetic.

Errors and limits

Diagrams simplify; real systems include caches, queues and monitoring tools.

Exercises

Synthesis

Know the parts, the request path and where other people's code runs.

Continue studying — chapter 02 of 40

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →