What the log4j incident taught us about Secure by Design
summary
The claim is that the December 2021 log4j JNDI/LDAP lookup exploitation becomes far harder if applications use domain primitives to validate inputs early and route logging through a domain-oriented logging API that encodes log output and separates audit/metrics stores. The design uses HTTP semantics (treat client 4xx as client faults), hexagonal subsystems, and defense‑in‑depth. Implementing these patterns reduces the exploitable surface dramatically — it does not guarantee zero risk but would have prevented most real‑world Log4Shell impact.
AI-written summary · about
chapters (16)
- 0:00Start
- 6:12Antatomy of the Log4j Attack
- 19:20Secure by Design Patterns Minimizing Log4j Impact
- 23:02Domain Primitives to Limit Attack Vectors
- 24:47Domain Primitives to protect logging
- 26:54Domain primitives takeaway
- 29:39Perimeter Based Security vs Security in Depth
- 30:18Hexagonal Security in Depth
- 31:37HTTP - request and response, status codes
- 32:26HTTP - request and response, when server errs
- 35:11HTTP - request and response, when client errs
- 38:16HTTP Takeaway
- 40:01Domain Primitives - Revised
- 41:45Logging seen as separate system
- 44:56The Domain Oriented Logging API decides how to log
- 48:21Logging with domain understanding
related talks
33mLog4J, SpringShell and all that Jazz (or why bad things can happen to good software)
51mDouble plus Ungood Why Log4Shell Is So Bad
51mLog4Shell Armageddon or Opportunity
17mLog4j - A Placement Student's Baptism by Fire
59mLog4j: Break Me Completely
46mThe Next Log4jshell?! Preparing for CVEs with eBPF!
25mDevSecOps by Default: What have, can and must we learn from Log4Shell?
02h 38mJava application security the hard way - a workshop for the serious developer