Session Identifier are for Now, Passwords are Forever - XSS-Based Abuse of Browser Password Managers
summary
Cross-site scripting lets JavaScript read passwords because browser managers insert plaintext into the DOM; major browsers differ — only Internet Explorer enforces strict URL/form matching or user interaction. Crawling Alexa Top 4000 finds password fields on 2,143 sites, 56% post passwords over HTTP, 13.6% use autocomplete=off, and 325 pages access fields with JS. A Firefox extension proof-of-concept replaces stored passwords with nonces and swaps them on submit; it works on ~98.6% of tested sites but fails when pages hash client-side, use XHR or send credentials in GET.
AI-written summary · about
chapters (25)
- 0:00Intro
- 0:22Browser choices
- 2:57The Same-Origin Policy
- 3:48XSS - the underlying problem
- 6:31XSS - what an attacker can do
- 8:08Types of XSS
- 8:42Isn't XSS so 2010?
- 10:24Passwords on the Web
- 12:40Solution: A Password Manager
- 13:51Password Managers and XSS
- 16:30Security Considerations
- 19:04Five key features of PW Managers
- 25:42HTML5 autocomplete
- 29:54Our notion vs. Google's notion
- 31:17What are login forms like out there?
- 33:46Analysis of Web password fields
- 35:58Similar attacker model
- 38:56Comparing the attacks
- 40:04Bottom line
- 41:44Mismatch in notion/implementations
- 42:42Our proposed solution
- 43:57Constraints for this approach
- 45:52PoC Implementation
- 47:40Functional evaluation
- 49:34What to take away!
related talks
34mBreaching the Perimeter via Cloud Synchronized Browser Settings
47mThe state of passwordless auth on the web
24mThe Emperor’s New Password Manager
18mEffective password management
29mYour Scripts In My Page - What Could Possibly Go Wrong?
41mThe Insecurity Caused By Trusting Your Client-Side Storage
51mThe state of passwordless auth on the web
40m"It Me": Under the Hood of Web Authentication