The Web’s Security Model Philippe De Ryck @PhilippeDeRyck https://www.websec.be 2 The Agenda for Today § The Same-Origin Policy § Setting a baseline with very relevant 20 year old technology § Third-Party Content Integration § Frame and script-based integration § Session Management § Cookies and the unavoidable CSRF attacks § Accessing Cross-Origin APIs § Extending the SOP with server-driven policies § Conclusion 3 About Me – Philippe De Ryck § Postdoctoral Researcher @ DistriNet (KU Leuven) § PhD on client-side Web security § Expert in the broad field of Web security § Main author of the Primer on Client-Side Web Security § Running the Web Security training program § Dissemination of knowledge and research results § Public training courses and targeted in-house training § Target audiences include industry and researchers @PhilippeDeRyck https://www.websec.be 4 The Same-Origin Policy 5 Same-Origin Policy § Separation based on origin § Default security policy enforced by the browser § Restricts the interactions between contexts of different origins § Protects applications from unintended interactions § First appeared in browsers in 1995, and still going strong ORIGIN SAME-ORIGIN POLICY The triple <scheme, host, port> Content retrieved from one derived from the document’s URL. origin can freely interact with For http://example.org/forum/, the other content from that origin, origin is <http, example.org, 80> but interactions with content from other origins are restricted 6 Examples of the Same-Origin Policy http://example.com SAME-ORIGIN POLICY http://example.com Content retrieved from one origin can freely interact with other content from that origin, but interactions with content http://forum.example.com from other origins are restricted http://private.example.com 7 Domains vs Subdomains § Subdomains § E.g. private.example.com vs forum.example.com § Considered different origin § Origin can be relaxed to example.com using document.domain § Possibility to use cookies on example.com § Completely separate domains § E.g. private.example.com vs exampleforum.com § Considered different origin, without possibility of relaxation § No possibility of shared cookies 8 Subdomains and Domain Relaxation www.example.com private.example.com forum.example.com account.example.com 9 Subdomains and Domain Relaxation www.example.com private.example.com forum.example.com account.example.com DOMAIN RELAXATION document.domain = “example.com”; 10 Subdomains and Domain Relaxation www.example.com private.example.com forum.example.com account.example.com DOMAIN RELAXATION document.domain = “example.com”; 11 But the SOP Is More than Context Isolation SAME-ORIGIN POLICY http://example.com Content retrieved from one origin can freely interact with http://example.com other content from that origin, http://example.com but interactions with content from other origins are restricted http://forum.example.com http://private.example.com http://private.example.com 12 Origin-Protected Resources § Modern browsers offer plenty of origin-protected resources § The DOM and all its contents § Client-side storage facilities • Web storage, In-browser file systems, Indexed DB § Permissions to various ”invasive” features • Geolocation, full-screen capabilities, media capture, … § WebRTC video and audio streams § Ability to load and inspect resources from same-origin servers § Ability to send XHR requests without restrictions § You want to be in control of what happens in your origin 13 Third-Party Content Integration 14 Third-Party Content Integration 15 Integration of Third-Party Code § Two mechanisms to integrate code § Embedding an iframe, which hosts a separate document § Directly including JavaScript code using the <script> tag § Iframes § Each iframe is a different context, with a separate origin § Preserves the security boundaries, but may hinder interaction § Scripts § Scripts are loaded and executed within the page’s context § Violates the security boundaries of a document 16 Iframe-based Content Integration § Iframes are controlled by the same-origin policy § Documents with different origins are isolated by the SOP § Well-suited to integrate separate components (e.g. advertisements) § Allows you to apply the principle of least privilege § More difficult to achieve dynamic interaction § HTML5 introduces the sandbox attribute § Supports disabling scripts, plugins, forms, etc. § Allows you to assign a unique origin to your content § Integrate untrusted content with a minimal set of capabilities 17 Interaction between Contexts § Related contexts § Documents can open popup windows, embed frames, etc. § Related cross-origin contexts are isolated by default § Limited interactions possible (navigation, messaging APIs, …) § Navigation § Navigate child frame to different resource § Navigate parent frame, reloading the entire document § Exposed APIs § Prime example: Web Messaging API, to support interaction 18 Web Messaging API § Messaging mechanism between contexts § Used for iframes, Web Workers, etc. § Event listener for receiving messages (opt-in mechanism) § API function for sending data (text, objects, etc.) § Security considerations § Specify origin of receiver to prevent leaking of content § Check origin of sender to prevent malicious use § Validate incoming content before using data to prevent injection attacks 19 Web Messaging API SENDING MESSAGES myframe.postMessage(data,'http://test.example.com'); RECEIVING MESSAGES var handler = function(event) { if(event.origin == 'http://www.example.com') { alert(event.data); } } window.addEventListener('message', handler, false); 20 Example: a Client-side Storage Facility https://storage.example.com/ Client-side Storage API Accessing local storage through Web Messaging allows enforcing access control and content inspection 21 Script-based Content Integration § No security boundaries offered by browser § Scripts are executed in the context that loads them § No boundaries between remote and local scripts § Full access to the client-side context, including local resources § Potentially dangerous setup § No more control if you include scripts from all over the place § Which has unfortunately become common practice 22 Large-scale Study of Remote JS Inclusions “88.45% of the Alexa top 10,000 web sites included at least one remote JavaScript library” 23 https://seclab.cs.ucsb.edu/media/uploads/papers/jsinclusions.pdf Large-scale Study of Remote JS Inclusions 24 https://seclab.cs.ucsb.edu/media/uploads/papers/jsinclusions.pdf Safely Including Third-Party Code § Leverage origin-based separation using iframes § Load the third-party script in a document with a different origin § SOP enforces isolation from the main origin and sensitive resources § Example case at Dropbox § They use a chat widget from a third-party provider § Inclusion in the main dropbox.com origin is an unacceptable risk § Widget loaded in an iframe with origin dbxsnapengage.com § Communication happens with Web Messaging 25 https://blogs.dropbox.com/tech/2015/09/csp-third-party-integrations-and-privilege-separation/ Reclaiming Control over Your Context § Say hello to Content Security Policy (CSP) § Main goal: prevent XSS attacks from causing harm § Allows you to specify where remote content can be loaded from § Allows you to specify where outgoing requests can go to § Policy specified by the server, enforced by the browser § Gives you control over your own code § Allows you to selectively load third-party code • And constrain what that code can do 26 Alternative Approaches to Constrain Scripts § Hosting scripts in your own origin § Difficult to deal with a highly dynamic codebase § Safe JavaScript subsets § Requires compatibility with existing scripts § Server-side rewriting § Requires control over the scripts to do the rewriting § Browser-based sandboxing § Requires browser modifications, which is a deployment nightmare § JavaScript-based sandboxing § Active research topic, may become possible in the coming years 27 Session Management 28 The Basics of Cookies § An HTTP state management mechanism § Set by the server to the client through the Set-Cookie header § Offered by the client to the server through the Cookie header Set-Cookie: name=value; Expires=Wed, 09 Jun 2021 10:18:14 GMT; Domain=example.com; Secure; HttpOnly Cookie: name=value § Cookie properties § If no expiration date is set, it is removed when the browser closes § If no domain is set, it is only valid for the domain that issued it • Otherwise, it is sent to the current domain and all subdomains 29 Using Cookies to Manage Sessions Some-shop.com Go to some-shop.com Hello stranger 13a99a4d1e8f496 Login as Philippe Logged_in: truefalse Hello Philippe User: Philippe Show orders Admin: true List of orders Go to some-shop.com 27ad3e9f78bc808 Hello stranger Logged_in: falsetrue Login as NotPhilippe User: NotPhilippe Hello NotPhilippe Admin: false 30 Properties of Cookie-Based Sessions § Session identifiers and objects are bearer tokens § The token represents ownership of the session § Cookies are managed by the browser § Stored automatically § Automatically attached to every request, if the domain matches § Common threats against cookie-based session management § Brute forcing a session identifier § Session hijacking and session fixation § Cross-Site Request Forgery 31 Cross-Site Request Forgery Illustrated Login as Philippe Hello Philippe Show orders List of orders some-shop.com Change email address Sure thing, Philippe Show latest blog post Latest blog post hackedblog.com 32 The Essence of CSRF § The server