Going Auth The Rails On A Crazy Train
summary
Rails apps use has_secure_password (bcrypt) but still leave session choice, expiration and reset flows to developers; cookie sessions serialize/encrypt state while database sessions store random IDs and are easier to revoke. A 2013 MySQL type‑confusion lets an attacker submit a numeric reset token (often 0) to reset the first outstanding token — a Metasploit module exists and the issue is patched in devis but persists in some app code. The team ships Boilerman, a dynamic rails‑console engine that enumerates controllers, actions and filters and finds missing API/token checks (demo exposes user tokens).
AI-written summary · about
chapters (7)
- 0:00Rails framework overview
- 3:41Authentication strategies
- 12:20Session management security
- 22:58Password reset mechanics
- 24:25Devise and common flaws
- 37:03Authorization practices
- 48:31Automated security auditing
related talks
27mGo Auth Urself
31mRails Application Security in Practice
43m...But Doesn't Rails Take Care of Security for Me?
34mThe World of Rails Security
24mUnraveling the black box: past, present and future of authentication in Rails
43mSecuring Your Rails App
32mSecuring Your Rails App
31mRails' Insecure Defaults