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

Facebook

(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

• 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

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 (sch@cs.berkeley.edu)

• Please visit our project web site– http://webblaze.cs.berkeley.edu

THANKS FOR LISTENING