1
The Emperor’s New APIsOn the (In)Secure Usage of New Client-side Primitives
Devdatta AkhaweSteve Hanna Eui Chul Richard Shin
Dawn Song
Arman Boehm Prateek Saxena
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
• 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
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)
MyWeatherApp.com Weather.compostMessage
To: Weather.comOrigin: www.myweatherapp.comData: “get_weather(94710)”
Sender Receiver
To: MyWeatherApp.comOrigin:www.weather.comData: “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
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
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
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
FB Connect Protocol Full details in paper
Implementor Facebook.comMake 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
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
Attacker
Implementor
Attacker
msg: (query, S) k
msg: (XSS)
targetOrigin: *
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
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
Attacker
Implementor (query, S)k
Facebook Connect Frame Hierarchy
proxyFrame
(query, S)k
(user data)
(user data)
(query, S)k
(user data)
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
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
Implementor Google.com
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
function get_name() {if (localStorage.name == ‘’) return prompt_name();else return localStorage.name;}
Example use of localStorage
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
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
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
– Primary XSS is main concern
– View as limitations of client-side database
– 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
To ensure application security, a primitive must minimize the liability that a developer undertakes.
• Minimize onus on developer
• Default fail-closed design
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
Suggested Enhancements:Client-side Storage
• Client-side storage– Database output sanitization - toStaticHTML-like functionality
localStorage.name = Joe<script>evil_code();</script>
InOut
JoeSanitizer
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 ([email protected])
• Please visit our project web site– http://webblaze.cs.berkeley.edu
THANKS FOR LISTENING