◇ OpenCyber Academy
Engineering · Chapter 13 · English

Chapter 13 — Data 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 13 — Data systems

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Database access"]
  N2["13.2 Injection"]
  N3["13.3 Sensitive fields"]
  N4["13.4 Backups for recovery"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Database access"]
  N2["13.2 Injection"]
  N3["13.3 Sensitive fields"]
  N4["13.4 Backups for recovery"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Database access]
    |
    v
[13.2 Injection]
    |
    v
[13.3 Sensitive fields]
    |
    v
[13.4 Backups for recovery]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) protect databases against common attacks; (2) control access to sensitive fields; (3) design backups that support recovery.

13.1 Database access

Saltmarsh's shipment database holds customer addresses and delivery notes. Lindiwe finds that the web application connects with an account that can read, change and delete every table. She recommends separate accounts for reading and writing, each limited to the tables needed. If the application were compromised, the attacker could then do less. Prof. Hale explains that database permissions are often granted broadly during development and never narrowed, so reviewing them is valuable early in any assessment. The developers create the two new accounts within a week.

13.2 Injection

Lindiwe studies how applications build database queries. Code that inserts user input directly into query text allows injection, where crafted input changes the query's meaning. She reviews a synthetic search page and finds it builds queries by joining strings. She rewrites it to use parameterised queries, so input is always treated as data. She learns that injection remains common because string building is easy, and that code review and testing must look for it specifically. She adds a test that submits a quotation mark and a semicolon.

13.3 Sensitive fields

Some fields, such as driver licence numbers, need stronger protection than others. Lindiwe considers encrypting them at the field level, so database administrators and backups see only ciphertext. Applications that need the values decrypt them with keys held separately. She notes the cost: searching and sorting encrypted fields becomes harder. Prof. Hale asks her to justify field encryption by who should and should not see values, not by a general wish to encrypt everything. She concludes that only licence numbers justify field encryption at Saltmarsh.

13.4 Backups for recovery

Backups protect availability and integrity, but only if they can be restored. Lindiwe learns that ransomware often targets backups first, so copies must be kept where an attacker who controls the main network cannot delete them. Saltmarsh keeps nightly backups on a network share reachable from servers. She recommends an additional copy that cannot be altered for a set period. She also notes that restores must be tested, a theme the course returns to with a verification lab. The infrastructure team prices the immutable copy.

Worked example

Lindiwe narrows database accounts, replaces string-built queries with parameterised ones, weighs field encryption for licence numbers and recommends immutable backup copies.

Synthetic case. Databases are synthetic.

Errors and limits

A backup reachable and deletable from the main network may not survive ransomware.

Exercises

Continue studying — lesson 13 (chapter 13 of 50)

← Chapter 12 · Course chapter index · Chapter 14 →

Continue to the next authored lesson.