Unit 7.3 · about 4 h
285 / 324Tenant isolation, input validation and injection
Assumes the Programming units on relational SQL queries and idempotent HTTP APIs as background. This unit takes their endpoint into the storage engine and the wire format, where one missing tenant predicate or one pickle load leaks or corrupts another tenant's data.
- explain
- implement
You can now
- Scope every data path by tenant identity and reject cross-tenant reads through normal, retry and cache paths.
- Replace string-built queries with parameterized queries and type-level SQL boundaries, and validate inputs with allowlists.
- Refuse native deserialization of untrusted bytes and use pure-data formats with signed envelopes where needed.
Covers
- Tenant identity, isolation and cross-tenant failure paths
- Input validation, injection, path and deserialization hazards
Study, in this order
4 steps
- Framework enforcement, SQL injection and XSS typesBuilding Secure and Reliable Systems - selected design route
Chapter 12, Writing Code: Frameworks to Enforce Security and Reliability (Example Framework for RPC Backends); SQL Injection Vulnerabilities:
TrustedSqlString, from the password-reset concatenation example through bound parameters and prepared statements; Preventing XSS:SafeHtml - Security boundaries, blast radius and data isolationBuilding Secure and Reliable Systems - selected design route
Chapter 8, Design for Resilience: Controlling the Blast Radius (Role Separation, Location Separation with Isolation of trust and Isolation of confidentiality); Failure Domains and Redundancies (Failure Domains with Data isolation)
- Allowlist validation and parsing disciplineOWASP Input Validation Cheat Sheet
Input Validation Strategies (Allowlist vs Denylist); Implementing Input Validation (Parse Safely, Then Validate; Validate Structured Data); Common Pitfalls (client-only checks, trusting internal sources, denylisting, logging rejected input verbatim)
- Safe deserialization rulesOWASP Deserialization Cheat Sheet
Python Clear-box Review (
pickle.loadandpickle.loads, unsafe PyYAML loaders,jsonpickle.decode); Language-Agnostic Methods (Using Alternative Data Formats, Only Deserialize Signed Data)
Focus on
- Tenant identity is an authorization input, not a request field: the query predicate comes from the authenticated context, never from the body.
- Parameterization plus type boundaries: bound parameters separate code from data, and
TrustedSqlString-style types make mixing impossible by construction. - Validate the representation that is used: decode once per protocol, then allowlist syntax and semantics. Denylists and client-only checks do not hold.
- Native formats execute:
pickle, unsafe YAML and type-driven JSON decoders run code at load time, so untrusted bytes get pure-data formats only.
Reproduce closed-book
acme' OR '1'='1 and show it returns both tenants' rows; then run the parameterized tenant-scoped query and show it returns only the caller tenant's single row. Then show pickle.loads executing a planted reduce call while json.loads of the same fields returns plain data.Traps
- Adding tenant checks on the main path but not on retry, cache-fill or restore paths. Every path that reads or writes tenant data needs the predicate and a test.
- Checking a deserialized object after loading it. Execution can happen during load, so the type test comes too late.
- Validating before the final decode. A downstream decode can change meaning after the check passed.
Practice
The section mini-project covers this: tenant-scoped queries across normal, retry, cache and restore paths, plus injection and deserialization tests with fixed fixtures.
Self-test
-
The tenant id arrives both in the auth token and the JSON body, and they disagree. Which one scopes the query?
The auth token. The body is untrusted input; the predicate uses the authenticated context. -
Why is a guideline to use prepared statements weaker than a
TrustedSqlString-style type?Guidelines need every developer and reviewer to comply every time. The type makes untrusted SQL construction impossible by construction. -
A cache fills a missed entry with another tenant's row and serves it on retry. Which boundary failed?
Tenant isolation on the cache-fill path. Every data path carries the tenant predicate, not only the primary query. -
Untrusted YAML arrives. Which loader, and why?
A safe loader that builds only plain data and blocks custom constructors, because unsafe loaders instantiate arbitrary objects.
Completion criterion
Stop when
Your scratch demo shows the bypass and the fix, and you can name every path where the tenant predicate must appear.
Mark passed, then open 7.4 Only mark this when you can do it without notes.Leads to
- 7.4 Audit records, fail-open versus fail-closed and supply chain Log tenant-scoped decisions with redacted telemetry.
- 6.1 Metrics, logs, traces, correlation and cardinality Keep tenant identifiers low-cardinality and secret-free in metrics and traces.
Comes after
- 7.2 Identity, authorization, least privilege and secretsScope the identities and credentials per tenant and test the cross-tenant paths.
Resources for this unit
- Building Secure and Reliable Systems - selected design route Read Chapters 1, 2, 4-9 and 12-14: adversaries, trade-offs, least privilege, understandability, changing landscapes, resilience, recovery, code, tests and deployment. Apply the chapter questions to the same RPC, store, tenant and migration boundary.
- OWASP Input Validation Cheat Sheet Apply allowlist validation, parse-safely-then-validate, structured-data rules, and the common pitfalls (client-only checks, trusted internal sources, denylisting, logging rejected input).
- OWASP Deserialization Cheat Sheet Apply the Python clear-box rules (
pickle, unsafe YAML loaders,jsonpickle) and the language-agnostic methods (pure-data formats, signed data).
Also in this section
- OpenDP theory - one bounded privacy mechanism Read A Framework to Understand DP and Differential Privacy with OpenDP (in the 0.16.0 user guide, Framework API), then Accuracy: Pitfalls and Edge Cases and the Differencing, Membership and Reconstruction attack notebooks. Define one privacy unit, clamp an aggregate, add calibrated noise, record \(\epsilon\) and \(\delta\) inputs, measure utility and list everything outside the guarantee.
- OWASP Threat Modeling Cheat Sheet Model trust boundaries, data flows, data stores, processes and external entities, and list the assets they carry. Write misuse cases for unauthorized mutation, cross-tenant reads, stale credentials, sensitive logs and restore or migration paths, then turn each into a test or explicit residual risk.
- OSTEP - introductory security chapters Use Chapters 53-56 for introductory security, authentication, access control and cryptography vocabulary. Connect process and container isolation to the threat model and state where those boundaries do not protect the system.
- Systems Foundations Checkpoint - security and privacy slice Use only the tenant-access, privacy aggregate, abuse, migration, backup and residual-risk requirements as the final assessment. A toy privacy mechanism is evidence for its stated aggregate, not a claim that the service or model is private.
- Data Privacy and Security (MIT Data-Centric AI) Read the threat-model examples, shadow-training and metrics-based membership attacks, extraction by sampling plus perplexity ranking, empirical-defense evaluation, and the \((\epsilon, \delta)\) definition with DP-SGD.
- A Survey of Privacy Attacks in Machine Learning Use the attack taxonomy and threat model (adversarial knowledge, assets under attack) plus the causes of leaks and the defenses overview; skip the per-paper catalog.
- Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning Read the weak threat model (no model or training-set knowledge, about 50 poisoning samples) and the reported result of above 90 percent attack success; skip the optimization details.