Ending Injection Vulnerabilities
summary
Claims that distinguishing strings from a trusted developer eliminates injection by forcing libraries to accept only programmer-defined SQL/HTML/CLI fragments and treat all other values as unsafe. Demonstrations use prepared queries, the go safe html library (compile-time string-constant checks that block unsafe concatenation), Closure Compiler goog.string.const, the isTemplateObject polyfill/tagged templates, Java Error Prone @CompileTimeConstant, and PHP static analysis plus an is_literal RFC. Measured overhead is a ~0.47 performance impact; many failures come from simple concatenation bugs.
AI-written summary · about
chapters (17)
- 0:00Start
- 1:08Distinguishing Strings from a Trusted Developer
- 3:19Injection Vulnerabilities
- 4:07Primarized Queries
- 8:06Character by Character Extraction
- 10:52Command Line Injection
- 11:30Taint Checking
- 14:31The Content Security Policy
- 19:01Dealing with Special Cases
- 21:02Table Names and Field Names
- 26:03Go Safety Html Library
- 27:59Ending Injection Vulnerabilities with Node and Javascript
- 28:36Tagged Templates
- 32:38Javascript and Trusted Types
- 35:25Java
- 41:07Rfc for Php
- 43:46Performance Impact
related talks
44mEnding Injection Vulnerabilities
54mTaking on the King: Killing Injection Vulnerabilities
48mSecuring Software’s Future
46mPopular Approaches to Preventing Code Injection Attacks are Dangerously Wrong
47mAdvances in Secure Coding Frameworks
35mPHP is evil (Defensive programming)
26mDangerous Reactivity: Why AI Output Is the New XSS
41mSecurity Vulnerabilities Decomposition: Another Way To Look At Vulnerabilities