webappsec.dev

$less ~/slides/recipe-for-scaling-web-security

// deck 01 · LocoMocoSec

A Recipe for Scaling (Web) Security

Lessons from Google's Frontlines

LocoMocoSec · Kaua'i · 2024keynote· 78 slides· Lukas Weichselbaum

pdf ↓ 7.3 MB

  1. Slide 1: #LocoMocoSec 2024
  2. Slide 2: Meet your Chef
  3. Slide 3: Menu
  4. Slide 4: Appetizer
  5. Slide 5: Web Originally vs Today
  6. Slide 6: Google makes heavy use of the web platform
  7. Slide 7: Google makes heavy use of the web platform (continued)
  8. Slide 8: A Framework for Classifying Domain Sensitivity
  9. Slide 9: Web Originally vs Today
  10. Slide 10: The web platform isn't safe by default
  11. Slide 11: The web platform isn't safe by default (continued)
  12. Slide 12: One of the Original Web Platform Sins: Injections
  13. Slide 13: The web platform isn't safe by default
  14. Slide 14: Web vulnerabilities are prevalent across the industry
  15. Slide 15: Web vulnerabilities are prevalent across the industry (continued)
  16. Slide 16: Remember LocoMocoSec 2019?
  17. Slide 17: Web vulnerabilities at Google ~5 years ago
  18. Slide 18: Fast forward
  19. Slide 19: Fast Forward
  20. Slide 20: Fast Forward (continued)
  21. Slide 21: Main Dish
  22. Slide 22: Loco Moco
  23. Slide 23: The three ingredients for obliterating
  24. Slide 24: The three ingredients for obliterating (continued)
  25. Slide 25: Addressing Root Causes
  26. Slide 26: Addressing Root Causes (continued)
  27. Slide 27: Addressing Root Causes (continued)
  28. Slide 28: The web platform isn't safe by default
  29. Slide 29: Addressing Root Causes
  30. Slide 30: But how to fix the web platform
  31. Slide 31: The Web is designed to be backward compatible
  32. Slide 32: The Web is designed to be backward compatible (continued)
  33. Slide 33: The Web is designed to be backward compatible (continued)
  34. Slide 34: The web platform is malleable!
  35. Slide 35: The web platform is malleable! (continued)
  36. Slide 36: Addressing Root Causes
  37. Slide 37: And sometimes it takes a tweet from Jim (and some help from Igalia)
  38. Slide 38: The Web is designed to be backward compatible
  39. Slide 39: The three ingredients for obliterating
  40. Slide 40: Securing Newly Written Code with Safe Coding
  41. Slide 41: Securing Newly Written Code with Safe Coding (continued)
  42. Slide 42: Securing Newly Written Code with Safe Coding (continued)
  43. Slide 43: Safe Coding - Developing software that is secure by design
  44. Slide 44: Safe Coding Benefits
  45. Slide 45: Securing Newly Written Code with Safe Coding
  46. Slide 46: Securing Newly Written Code with Safe Coding (continued)
  47. Slide 47: Securing Newly Written Code with Safe Coding (continued)
  48. Slide 48: Safe defaults in our hardened frameworks
  49. Slide 49: A typical response* from our
  50. Slide 50: A typical response* from our (continued)
  51. Slide 51: A typical response* from our (continued)
  52. Slide 52: The path to zero XSS
  53. Slide 53: The path to zero XSS Runtime protections are highly effective to
  54. Slide 54: The path to zero XSS
  55. Slide 55: The path to zero XSS (continued)
  56. Slide 56: The path to zero XSS (continued)
  57. Slide 57: CSP Evaluator
  58. Slide 58: The three ingredients for obliterating
  59. Slide 59: Fixing Legacy Code at Scale
  60. Slide 60: Fixing Legacy Code at Scale (continued)
  61. Slide 61: Fixing Legacy Code at Scale (continued)
  62. Slide 62: Fixing Legacy Code at Scale (continued)
  63. Slide 63: However, fixing legacy code at scale can work!
  64. Slide 64: However, fixing legacy code at scale can work! (continued)
  65. Slide 65: However, fixing legacy code at scale can work! (continued)
  66. Slide 66: However, fixing legacy code at scale can work! (continued)
  67. Slide 67: Fixing Legacy Code at Scale
  68. Slide 68: Fixing Legacy Code at Scale – Public resources
  69. Slide 69: Security Signals
  70. Slide 70: Security Signals (continued)
  71. Slide 71: Security Signals (continued)
  72. Slide 72: Dessert
  73. Slide 73: Key Takeaways
  74. Slide 74: Key Takeaways (continued)
  75. Slide 75: Key Takeaways (continued)
  76. Slide 76: Key Takeaways (continued)
  77. Slide 77: Together, let's strive to build a web that's
  78. Slide 78: Mahalo
1 / 78

// key slides

  1. 6Google's web footprint: 600+ subdomains, 900+ sensitive apps, a trillion requests
  2. 36Patching in app code is easy but does not scale; patching the platform scales most
  3. 48Twelve security features, each moved from opt-in to default to enforced
  4. 64Strict CSP coverage climbing past 900 apps since 2019

// what you take away

  • Fix a bug class in the browser or the framework, not in each app. That is what scales.
  • Hardened frameworks ship new apps with strict CSP and Trusted Types built in.
  • Inventory, violation reports and automated patches put strict CSP on 900+ apps.