The Emperor’s New APIs On the (In)Secure Usage of New Client-side Primitives

1. The Emperor’s New APIsOn the (In)Secure Usage of New Client-side Primitives Steve Hanna Eui Chul Richard Shin Devdatta Akhawe Arman Boehm Prateek Saxena Dawn Song University of California, Berkeley

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

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. Goals Are these new primitives used securely in practice? • Two representative examples • postMessage a secure channel for cross-origin communication • localStorage – a client-side database primitive

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. Outline • postMessage Case Study • localStorage Case Study • Discussion with Vendors • Suggested Enhancements • Conclusion

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

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

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

11. Mozilla Dev Center Warning • From MDC postMessage page

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

13. Facebook Connect Attack: Integrity Attack on Integrity Facebook Connect Frame Hierarchy (proxyFrame replaced with attacker controlled proxyFrame) 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. Attacker Implementor Attacker Attacker msg: (query, S)k targetOrigin: * msg: (XSS) targetOrigin: *

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

15. Facebook Connect Attack: Confidentiality Attack on Confidentiality Facebook 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 Attacker (query, S)k proxyFrame (query, S)k (user data) (user data) (user data) Facebook Connect Frame Hierarchy

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

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 Implementor Google.com Make gadget frame (ID, N, session, origin)) (code for gadget) msg: (Q, N) (query) (user info) msg: (P, N) gadget frame Full details in paper

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. Google Friend Connect Attack Severity • GFC Session Integrity Compromised • Parameters changed by spoofing msg • Example compromised gadget

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

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 Example use of localStorage function get_name() { if (localStorage.name == ‘’) return prompt_name(); else return localStorage.name; }

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 aserver-oblivious, persistentclient-side XSS attack.

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

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. 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. 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. Economy of Liabilities • Minimize onus on developer • Default fail-closed design To ensure application security, a primitive must minimize the liability that a developer undertakes.

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 functioncompare_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. Suggested Enhancements:Client-side Storage Client-side storage Database output sanitization - toStaticHTML-like functionality localStorage.name = Joe<script>evil_code();</script> Sanitizer In Out Joe Enable sanitization?

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. Contact • Contact: • Steve Hanna (sch@cs.berkeley.edu) • Please visit our project web site • http://webblaze.cs.berkeley.edu THANKS FOR LISTENING