Docstoc

The Emperor's New APIs

Document Sample
The Emperor's New APIs Powered By Docstoc
					         The Emperor‟s New APIs
 On 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



                                                                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                              To: MyWeatherApp.com
 Origin: www.myweatherapp.com                 Origin:www.weather.com
 Data: “get_weather(94710)”                   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
               window.addEventListener("message", getMessage, false);
               function getMessage(event) {
Origin Check    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
               window.addEventListener("message", getMessage, false);
               function getMessage(event) {
Origin Check    /*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

                Implementor                 Facebook.com




                               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
                                        Attacker
messages were verified
                                          Implementor
Lack of origin checks allow
                                              Attacker
                                             Attacker
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.



                                                                                           13
            FBC Severity: Integrity
• Allows XSS at benign Implementor’s Origin

– Only query verified, not response




                                              14
   Facebook Connect Attack: Confidentiality

Attack on Confidentiality         Facebook

Messages to proxyFrame
targetOrigin parameter set to
broadcast.                            Attacker

                                       Implementor
Leaks confidential information,
like profile and identity.                   Attacker
                                          proxyFrame
Because sender query not
verified, allows a MITM attack.




                                      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



                                                                Client-side
                                                                Database
                                          Victim’s Computer




                                                                      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
                                                                   Joe
                                             Sanitizer




                                                         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

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:3
posted:5/4/2011
language:English
pages:31