1. 1 The Emperor’s New APIs On the (In)Secure Usage of New Client-side Primitives Devdatta AkhaweSteve HannaEui Chul Richard Shin Dawn Song Arman BoehmPrateek Saxena University of California, Berkeley

2. 2 New Web Primitives New HTML5 primitives enhance user experience Facebook Connect, Google Friend Connect –Identity provider, rich user experience

3. 3 Changing Web Landscape Web applications changing to meet consumer needs Application logic is shifting Users’ expectations are changing Demand greater functionality Platform flexibility

4. 4 Goals Two representative examples postMessage a secure channel for cross-origin communication localStorage – a client-side database primitive Are these new primitives used securely in practice?

5. 5 Contributions A study of new client-side primitive use in practice –We examine two representative client-side primitives Provide evidence of pervasiveness of attacks Principles from lessons learned –Discussed vulnerabilities with vendors –We propose the Economy of Liabilities, Guiding Principle Suggested Enhancements –postMessage and client-side storage enhancements

6. 6 Outline postMessage Case Study localStorage Case Study Discussion with Vendors Suggested Enhancements Conclusion

7. 7 postMessage Overview postMessage used for cross-origin communication –Limitations of AJAX, server to server communication Usage: targetWindow.postMessage(msg, targetOrigin ) MyWeatherApp.com Weather.com postMessage To: Weather.com Origin: www.myweatherapp.comwww.myweatherapp.com Data: “get_weather(94710)” Sender Receiver To: MyWeatherApp.com Origin:www.weather.comwww.weather.com Data: “Sunny,75”

8. 8 Secure Channel Abstraction postMessage guarantees confidentiality and authenticity –Confidentiality: Sender specifies recipient’s origin (targetOrigin) »targetOrigin can be ‘*’, which is broadcast –Authenticity: Browser attribs. msg with the sender’s origin (Origin) Key Point: If checks omitted, security of postMessage not assured otherWindow.postMessage(msg, targetOrigin )

9. 9 Default Fail-Open Design Sample postMessage usage from Mozilla Dev Center var popup = window.open(...popup details...); popup.postMessage(“hi!", "http://bob.org"); Running on http://alice.org window.addEventListener("message", getMessage, false); function getMessage(event) { if (event.origin !== "http://alice.org") return; alert(event.data); } Running on http://bob.org What happens if the origin check is removed? targetOrigin Origin Check

10. 10 Default Fail-Open Design Sample postMessage usage from Mozilla Dev Center var popup = window.open(...popup details...); popup.postMessage(“hi!", "http://bob.org"); Running on http://alice.org Running on http://bob.org The application functionality remains the same! targetOrigin window.addEventListener("message", getMessage, false); function getMessage(event) { /*snipped*/ alert(event.data); } Origin Check

11. 11 Mozilla Dev Center Warning From MDC postMessage page

12. 12 Facebook Connect FBC enables users to use 3rd party sites with FB identity We reverse engineered FBC protocol FB Connect ProtocolFull details in paper Implementor Facebook.com Make login frame (API key, origin) (S, K, origin) msg: (S, K) make proxy get proxy code code for proxy (query, S) K (user data) proxyFrame msg: (query, S) K msg: (user data) loginFrame

13. 13 Facebook Connect Attack: Integrity Attack on Integrity The origin of half of the messages were verified Lack of origin checks allow attacker to inject arbitrary data in the communication between the implementor and proxyFrame. Attacker can replace the proxyFrame with own frame. This allows the attacker to fully XSS the implementor. Facebook Connect Frame Hierarchy (proxyFrame replaced with attacker controlled proxyFrame) Attacker Implementor Attacker msg: (query, S) k msg: (XSS) targetOrigin: *

14. 14 FBC Severity: Integrity Allows XSS at benign Implementor’s Origin –Only query verified, not response

15. 15 Facebook Connect Attack: Confidentiality Attack on Confidentiality Messages to proxyFrame targetOrigin parameter set to broadcast. Leaks confidential information, like profile and identity. Because sender query not verified, allows a MITM attack. Attacker Implementor (query, S) k Facebook Connect Frame Hierarchy proxyFrame Facebook (query, S) k (user data) (query, S) k (user data)

16. 16 FBC Severity: Confidentiality Leaks confidential user info –Friends, Contact Information, Political Associations, etc.

17. 17 Google Friend Connect Google Friend Connect allows a Google user to share multiple online identities with third-party sites. We reverse engineered the GFC Protocol Google Friend Connect Protocol Full details in paper Make gadget frame (ID, N, session, origin)) (code for gadget) msg: (Q, N) (query) (user info) msg: (P, N) gadget frame ImplementorGoogle.com

18. 18 Google Friend Connect Attack Attack targetOrigin correctly set but analysis code revealed absence of sender authenticity checks Protocol instead checks for correct nonce Predicting nonce leads to spoof of message exchanged by gadget and implementor Google Friend Connect Gadget

19. 19 Google Friend Connect Attack Severity GFC Session Integrity Compromised –Parameters changed by spoofing msg –Example compromised gadget

20. 20 Outline postMessage Case Study localStorage Case Study Suggested Enhancements Discussion with Vendors Conclusion

21. 21 Client-side Storage Overview localStorage/webStorage for creating persistent, client-side databases –localStorage simple name/value pair –webStorage SQL capable database interface Browser guarantees isolation based on origin function get_name() { if (localStorage.name == ‘’) return prompt_name(); else return localStorage.name; } Example use of localStorage

22. 22 Client-side Storage Potential Threat Web apps store data on the client-side to enable rich web experience Database output must be verified and sanitized –If not, this can lead to a server-oblivious, persistent client-side XSS attack.

23. 23 Client-side Threat Model We consider 2 potential threat models –Primary XSS Attack Vector –Network Attacker Example scenarios Client-side Database XSS Malicious Code Victim’s Computer

24. 24 Client-side Storage Evaluation Evaluated applications that utilized client-side storage Found 7/11 apps were vulnerable to persistent, client-side XSS attacks Persistent, client-side XSS –Google Gmail, Buzz, Documents, Maps Transient client-side XSS –Google Reader, Zoho Documents Invulnerable –Google Calendar, Translate

25. 25 Vendor Discussion Google –Primary XSS is main concern –View as limitations of client-side database Facebook –50% of users’ browsers support postMessage –Otherwise fragment identifiers and Flash –Facebook response: disabled postMessage

26. 26 Lessons Learned Developers within same org used primitive incorrectly Custom sanity checks and verification –Easy to make mistakes/omit checks –Not scalable Design for browser compatibility

27. 27 Economy of Liabilities To ensure application security, a primitive must minimize the liability that a developer undertakes. Minimize onus on developer Default fail-closed design

28. 28 Suggested Enhancements: postMessage Origin Whitelist –Extend Content Security Policy (CSP) »Site declaratively specifies origins allowed to postMessage –Ensures confidentiality/authenticity, restricts targetOrigin/Origin Origin Comparison Primitive –Reduces developer burden X-Content-Security-Policy: post-msg-senders *.example.com *.facebook.com post-msg-recip*.example.com *.facebook.com function compare_origins(msg_origin, [array of acceptable origins]); Input: message origin (event.origin), array of acceptable origins (ex. [example.com]) Output: 0 if invalid origin, otherwise an integer index into the array

29. 29 Suggested Enhancements: Client-side Storage Client-side storage –Database output sanitization - toStaticHTML-like functionality localStorage.name = Joe evil_code(); In Out Joe Sanitizer Enable sanitization?

30. 30 Conclusion Evaluated security of new primitives in practice –postMessage »Reverse engineered Facebook/Google Friend Connect »Often used securely, but devs in the same org make mistakes –localStorage »Examined high profile applications (Gmail, Buzz, Docs, etc) »Widely used without sanitization Discussed vendor reasoning and responses Enhancements using Economy of Liabilities as guiding principle –Increase their ease of use –Reduce developer burden –Increase overall security

31. 31 Contact Contact: –Steve Hanna (sch@cs.berkeley.edu) Please visit our project web site –http://webblaze.cs.berkeley.eduhttp://webblaze.cs.berkeley.edu THANKS FOR LISTENING