The Emperor’s New APIs
On the (In)Secure Usage of New Client-side Primitives
Steve Hanna
Eui Chul Richard Shin
Arman Boehm
Devdatta Akhawe
Prateek Saxena
Dawn Song
University of California, Berkeley
1
New Web Primitives
• New HTML5 primitives enhance user experience
• Facebook Connect, Google Friend Connect
– Identity provider, rich user experience
2
Changing Web Landscape
• Web applications changing to meet consumer needs
• Application logic is shifting
• Users’ expectations are changing
• Demand greater functionality
• Platform flexibility
3
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
4
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
5
Outline
• postMessage Case Study
• localStorage Case Study
• Discussion with Vendors
• Suggested Enhancements
• Conclusion
6
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”
7
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)
8
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
Origin Check
window.addEventListener("message", getMessage, false);
function getMessage(event) {
if (event.origin !== "http://alice.org") return;
alert(event.data);
}
What happens if the
origin check is
removed?
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
Origin Check
window.addEventListener("message", getMessage, false);
function getMessage(event) {
/*snipped*/
alert(event.data);
}
The application
functionality remains
the same!
10
Mozilla Dev Center Warning
• From MDC postMessage page
11
Facebook Connect
• FBC enables users to use 3rd party sites with FB identity
• We reverse engineered FBC protocol
Facebook.com
Implementor
loginFrame
FB Connect Protocol
Full details in paper
proxyFrame
12
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
Attacker
Implementor
Lack of origin checks allow
attacker to inject arbitrary data in
the communication between the
implementor and proxyFrame.
Attacker
Attacker
Attacker can replace the
proxyFrame with own frame.
This allows the attacker to fully
XSS the implementor.
13
FBC Severity: Integrity
• Allows XSS at benign Implementor’s Origin
– Only query verified, not response
14
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.
Facebook
Attacker
Implementor
Attacker
proxyFrame
Facebook Connect Frame Hierarchy
15
FBC Severity: Confidentiality
• Leaks confidential user info
– Friends, Contact Information, Political Associations, etc.
16
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
gadget frame
Full details in paper
17
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
18
Google Friend Connect Attack Severity
• GFC Session Integrity Compromised
– Parameters changed by spoofing msg
– Example compromised gadget
19
Outline
• postMessage Case Study
• localStorage Case Study
• Suggested Enhancements
• Discussion with Vendors
• Conclusion
20
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;
}
21
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.
22
Client-side Threat Model
• We consider 2 potential threat models
– Primary XSS Attack Vector
– Network Attacker
•
Example scenarios
Malicious Code
Victim’s Computer
Client-side
Database
23
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
24
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
25
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
26
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
27
Suggested Enhancements:
postMessage
• Origin Whitelist
– Extend Content Security Policy (CSP)
» Site declaratively specifies origins allowed to postMessage
– Ensures confidentiality/authenticity, restricts targetOrigin/Origin
X-Content-Security-Policy: post-msg-senders *.example.com *.facebook.com
post-msg-recip*.example.com *.facebook.com
• Origin Comparison Primitive
– Reduces developer burden
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
28
Suggested Enhancements:
Client-side Storage
• Client-side storage
– Database output sanitization - toStaticHTML-like functionality
localStorage.name = Joe<script>evil_code();</script>
In
Out
Sanitizer
Joe
Enable sanitization?
29
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
30
Contact
• Contact:
– Steve Hanna (sch@cs.berkeley.edu)
• Please visit our project web site
– http://webblaze.cs.berkeley.edu
THANKS FOR
LISTENING
31