✳ Field lesson A5b / 10 min

Database integrity and what answers reveal

A database protects data in two ways. ACID transactions keep it whole, even through a crash. Access rules keep it hidden, but permitted answers can still be combined to reveal a secret. That leak is called inference.

appsecdatabasesintegrityinferenceaggregation

Helpful first: Security in every phase of development

Thirty days to Halcyon · Case 11: Prove it · Episode 8 of 9

The auditors arrive tomorrow. They have named the system they will inspect: the maneuver-booking database.

Vera Vance, your mentor, pulls up one booking. It debits a fuel quota, then reserves a burn window. "Suppose the power fails between those two steps. What is true afterward?"

Kael Cho, Staff Infrastructure Engineer, starts to answer, stops, and looks at you.

By the end you can

  • Name the ACID property that a given database failure breaks
  • Tell aggregation from inference in a described leak
  • Explain how polyinstantiation closes one inference channel

A booking must be whole

One booking does two things. It debits a tenant's fuel quota, and it reserves a burn window. Vera's question is what happens if the power fails between them. If the debit stays and the reservation is lost, a customer has paid for nothing. The data no longer describes what happened.

A relational database guards against this in two ways. The first is referential integrity. A primary key is the value that identifies a row. A foreign key is a reference from one row to another row's primary key. Referential integrity means every foreign key must match an existing primary key, or be null. A reservation cannot point at a tenant that does not exist.

The second is the transaction. A transaction groups several operations so the database treats them as one unit. The debit and the reservation belong in one transaction. The promises a transaction makes go by the name ACID.

  1. BeginTransaction opens
  2. Debit fuel quota
  3. Reserve burn window
  4. CommitBoth changes become permanent together
One booking, one transaction. The failure point is the gap in the middle. A transaction makes the database treat all four steps as one.

The four promises of a transaction

ACID stands for atomicity, consistency, isolation, and durability. Each letter is one promise.

Atomicity means all or nothing. Every operation in the transaction succeeds, or the whole transaction rolls back. Consistency means the database's constraints and rules hold before the transaction and after it.

Isolation covers transactions that run at the same time. They execute as if they ran one after another, and none of them leaks its intermediate state to the others. Durability covers crashes. A committed transaction is written to a non-volatile log, so it survives.

Now you can answer Vera. If the power fails after the debit, atomicity rolls the debit back. The tenant's quota is as it was. If the power fails just after the commit, durability keeps both changes.

The ACID properties
PropertyThe promiseFor the booking
AtomicityAll operations succeed, or the entire transaction rolls back.No debit without a reservation.
ConsistencyConstraints and rules are preserved before and after the transaction.The booking cannot break a rule the database enforces.
IsolationConcurrent transactions execute as if serialized, without leaking intermediate state.Nobody sees a half-finished booking.
DurabilityCommitted transactions are written to non-volatile logs and survive crashes.A confirmed booking is still there after a restart.

SORT IT OUT

The auditors describe four things the booking database does. Which ACID property is each one showing?

  1. Power fails after the debit. On restart, the debit has been undone.

  2. A booking confirmed at 14:00 is still present after a crash at 14:01.

  3. A second session cannot see a booking's debit until the whole booking commits.

  4. A booking that would break one of the database's own rules is refused.

Show the answers
  1. Atomicity. The transaction did not finish, so all of it rolled back.
  2. Durability. Once committed, the change is in a non-volatile log and survives the crash.
  3. Isolation. Intermediate state does not leak to other transactions.
  4. Consistency. Constraints hold before and after every transaction.

When permitted answers add up to a secret

Integrity is half of database security. The other half is what the answers reveal. In a multi-level secure database, records carry different classification levels. Two subtle leaks can occur even when row-level permissions are enforced.

Aggregation happens when a user collects many low-sensitivity records. Combined, they exceed the classification of the individual records. Inference happens when a user logically deduces a restricted fact from the low-classification answers they are allowed to see.

Vera shows the auditors an example. A logistics contractor may see fuel delivery totals and overtime rosters for Station South. Neither is sensitive. Together they show a large delivery and a full night crew on one date. Collecting those records is aggregation. Working out the date of a restricted maneuver from them is inference.

Every query in that example was allowed. No permission failed. The leak is in the combination.

Aggregation

  • Collects many low-sensitivity records
  • The combined set is more sensitive than its parts
  • Example: delivery totals plus rosters

Inference

  • Deduces a restricted fact
  • Uses only permitted answers
  • Example: the maneuver date
Aggregation versus inference. Aggregation is the collecting. Inference is the deducing. One often feeds the other.

Polyinstantiation hides that a secret exists

One inference channel hides in an error message. Suppose a restricted maneuver is stored under a primary key. A lower-cleared user tries to insert a row with the same key. If the database refuses because the key exists, it has revealed that a secret record is there.

Polyinstantiation closes that channel. It permits several rows to share one primary key at different classification levels. The lower-cleared user's insert succeeds. No error tells them that a secret record already exists.

Polyinstantiation counters this one channel. It does not stop a user from combining totals, as the contractor did. Each leak needs its own answer.

YOUR CALL

The auditors try two things

An auditor signs in with a low-clearance test account. A restricted maneuver is already stored under key M-0412.

  1. The auditor inserts a low-sensitivity row with the key M-0412. What should the database do?

  2. The auditor then runs two permitted queries: fuel delivery totals and overtime rosters. Sloane asks whether that needs a finding.

Show the strong calls
  1. Accept the row as a separate instance at the lower level. The insert succeeds without comment. The auditor learns nothing about what else is stored under that key.
  2. Yes. Review what those permitted results reveal when combined. You line the two results up. One date stands out in both. Sloane assigns an owner and a due date.

CHECK YOUR JUDGMENT

A contractor cleared only for low-sensitivity logistics data queries two totals at Station South: catering deliveries and temporary bunk assignments. By correlating the two, the contractor works out the exact date of an unannounced, restricted test. Which database security threat has occurred?

CASE FILE · CASE 11 · ENTRY 8 OF 9

Answer the closing question correctly to add this entry to your case file.

Whole bookings, leaky totals

A half-finished booking rolls back whole, yet two permitted totals still gave away a restricted maneuver date: integrity held and inference leaked.

Next episode: Kael has found something worse. Two bookings sent together can spend the same fuel twice.

Open the case file ↗

Review sheet: exam notes and quick reference

NEXT EPISODE

Classic application attacks and their root fixes

↗

Find your next idea.

Tip: press / to open search. Escape closes this window.