Securing the JVM
summary
Demos show easy JVM attacks: using the reflection API to read and change private fields and even swap types at runtime, hot-patching bytecode in a running Spring app without restart, and hiding Java source inside images via steganography then compiling and executing it on the fly with a public steganography library. Hardening uses the security manager and per-app policy files (one demo produced a ~250‑line policy, with messy workarounds like granting all system property reads for a JCache bug).
AI-written summary · about
chapters (23)
- 0:00Introduction
- 1:55What color is Switzerland
- 2:26Everybody is rich
- 2:42We are the best
- 2:58Swiss Passport
- 3:33Meet Nicolas
- 4:06Cloud Act
- 5:05Quiz
- 12:46Safeguards
- 15:32Steganography
- 15:58Demo
- 18:11Imagine
- 21:36Danger
- 22:10applets
- 22:32security manager
- 24:06Permissions
- 25:05Default Policy File
- 26:48Less Privileges
- 29:17All Permission
- 30:45Policy File
- 31:01Example
- 38:49Shortcuts
- 43:16References
related talks
43mDon't hack the JVM? ☠️💣💥
48mHidden Security Features of the JVM - Everything You Didn’t Know and More
43mLive hacking: Breaking into your Java web app
46mStrengthening Java Apps: Best Practices in Secure Coding for Java Developers
02h 38mJava application security the hard way - a workshop for the serious developer
48mThe Hidden Security Hazards in Your Java Stack
44mJava Code Security
46mPopular Approaches to Preventing Code Injection Attacks are Dangerously Wrong