Web Security Fundamentals: Understanding the Same Origin Policy

Explore the basic principles of web security focusing on the Same Origin Policy, operating system analogies, isolation of content sources, browser sandboxing, and setting cookies securely by servers. Learn how these concepts help ensure a safe browsing experience and prevent common vulnerabilities like cross-site scripting and request forgery.

• Web Security
• Same Origin Policy
• Isolation
• Browser Sandbox
• Cookies

fwol Follow

Uploaded on Oct 03, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. CS 4413/6013: Secure Electronic Commerce Spring 2019 Basic Web Security Model: The Same-Origin Policy and Implications Tyler Moore Many slides from John Mitchell, Stanford Web Security Group and Vitaly Shmatikov, Cornell 1

2. Analogy Operating system Primitives System calls Processes Disk Principals: Users Discretionary access control Vulnerabilities Buffer overflow Root exploit Web browser Primitives Document object model Frames Cookies / localStorage Principals: Origins Mandatory access control Vulnerabilities Cross-site scripting Cross-site request forgery 2

3. ISOLATION 3

4. Content Comes from Many Sources u Scripts <script src= //site.com/script.js > </script> u Frames <iframe src= //site.com/frame.html > </iframe> u Stylesheets (CSS) <link rel= stylesheet type="text/css href= //site.com/theme.css" /> u Objects (Flash) - using swfobject.js script <script> var so = new SWFObject( //site.com/flash.swf', ); so.addParam( allowscriptaccess', always'); so.write('flashdiv'); </script> scripts, navigate frames, open windows Allows Flash object to communicate with external slide 4

5. Browser Sandbox u Goal: safely execute JavaScript code provided by a website No direct file access, limited access to OS, network, browser data, content that came from other websites u Same origin policy Can only access properties of documents and windows from the same domain, protocol, and port u User can grant privileges to signed scripts UniversalBrowserRead/Write, UniversalFileRead, UniversalSendMail slide 5

6. Same Origin Policy protocol://domain:port/path?params Same Origin Policy (SOP) for DOM: Origin A can access origin B s DOM if A and B have same (protocol, domain, port) Same Origin Policy (SOP) for cookies: Generally, based on ([protocol], domain, path) optional slide 6

7. Setting Cookies by Server GET Browser Server HTTP Header: Set-cookie: NAME=VALUE; domain = (when to send); path = (when to send); secure = (only send over HTTPS); expires = (when expires); HttpOnly scope if expires=NULL: this session only Delete cookie by setting expires to date in past Default scope is domain and path of setting URL slide 7

8. Viewing Cookies in Browser slide 8

9. Cookie Identification Cookies are identified by (name, domain, path) cookie 1 name = userid value = test domain = login.site.com path = / secure cookie 2 name = userid value = test123 domain = .site.com path = / secure distinct cookies Both cookies stored in browser s cookie jar, both are in scope of login.site.com slide 9

10. SOP for Writing Cookies domain: any domain suffix of URL-hostname, except top-level domain (TLD) Which cookies can be set by login.site.com? allowed domains login.site.com .site.com disallowed domains user.site.com othersite.com .com login.site.com can set cookies for all of .site.com but not for another site or TLD Problematic for sites like .utulsa.edu path: anything slide 10

11. SOP for Sending Cookies GET //URL-domain/URL-path Cookie: NAME = VALUE Browser Server Browser sends all cookies in URL scope: cookie-domain is domain-suffix of URL-domain cookie-path is prefix of URL-path protocol=HTTPS if cookie is secure Goal: server only sees cookies in its scope slide 11

12. Examples of Cookie SOP cookie 1 name = userid value = u1 domain = login.site.com path = / secure both set by login.site.com cookie 2 name = userid value = u2 domain = .site.com path = / non-secure http://checkout.site.com/ http://login.site.com/ https://login.site.com/ cookie: userid=u2 cookie: userid=u2 cookie: userid=u1; userid=u2 (arbitrary order; in FF3 most specific first) slide 12

13. Cookie Protocol Issues u What does the server know about the cookie sent to it by the browser? u Server only sees Cookie: Name=Value does not see cookie attributes (e.g., secure ) does not see which domain set the cookie RFC 2109 (cookie RFC) has an option for including domain, path in Cookie header, but not supported by browsers slide 13

14. Who Set The Cookie? u Alice logs in at login.site.com login.site.com sets session-id cookie for .site.com u Alice visits evil.site.com Overwrites .site.com session-id cookie with session-id of user badguy - not a violation of SOP! (why?) u Alice visits cs6013.site.com to submit homework cs7403.site.com thinks it is talking to badguy u Problem: cs6013.site.com expects session-id from login.site.com, cannot tell that session-id cookie has been overwritten by a sibling domain slide 14

15. Overwriting Secure Cookies u Alice logs in at https://www.google.com https://www.google.com/accounts u Alice visits http://www.google.com Automatically, due to the phishing filter u Network attacker can inject into response Set-Cookie: LSID=badguy; secure Browser thinks this cookie came from http://google.com, allows it to overwrite secure cookie LSID, GAUSR are secure cookies slide 15

16. Accessing Cookies via DOM u Same domain scoping rules as for sending cookies to the server u document.cookie returns a string with all cookies available for the document Often used in JavaScript to customize page u Javascript can set and delete cookies via DOM document.cookie = name=value; expires= ; document.cookie = name=; expires= Thu, 01-Jan-70 slide 16

17. Path Separation Is Not Secure Cookie SOP: path separation when the browser visits x.com/A, it does not send the cookies of x.com/B This is done for efficiency, not security! DOM SOP: no path separation A script from x.com/A can read DOM of x.com/B <iframe src= x.com/B"></iframe> alert(frames[0].document.cookie); slide 17

18. Caution: <script> tags exempt from Same-Origin Policy! u Same origin policy does not apply to directly included scripts (not enclosed in an iframe) <script type="text/javascript" src=https://seal.verisign.com/getseal?host_name=A.com> </script> VeriSign This script has privileges of A.com, not VeriSign Can change other pages from A.com origin, load more scripts Upshot: Never load an external script that you don t completely trust with a <script> tag slide 18

19. NAVIGATION slide 19

20. Frames and iFrames u Window may contain frames from different sources frame: rigid division as part of frameset iframe: floating inline frame <IFRAME SRC="hello.html" WIDTH=450 HEIGHT=100> If you can see this, your browser doesn't understand IFRAME. </IFRAME> u Why use frames? Delegate screen area to content from another source Browser provides isolation based on frames Parent may work even if frame is broken slide 20

21. Browser Security Policy for Frames A B A A B u Each frame of a page has an origin Origin = protocol://domain:port u Frame can access objects from its own origin Network access, read/write DOM, cookies and localStorage u Frame cannot access objects associated with other origins slide 21

22. Mashups slide 22

23. iGoogle (Now Defunct) slide 23

24. Cross-Frame Scripting u Frame A can execute a script that manipulates arbitrary DOM elements of Frame B only if Origin(A) = Origin(B) Basic same origin policy, where origin is the protocol, domain, and port from which the frame was loaded u Some browsers used to allow any frame to navigate any other frame Navigate = change where the content in the frame is loaded from Navigation does not involve reading the frame s old content u http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_win_frames http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_win_frames slide 24

25. Frame SOP Examples Suppose the following HTML is hosted at site.com u Disallowed access <iframe src="http://othersite.com"></iframe> alert( frames[0].contentDocument.body.innerHTML ) alert( frames[0].src ) u Allowed access <img src="http://othersite.com/logo.gif"> alert( images[0].height ) or frames[0].location.href = http://mysite.com/ Navigating child frame is allowed, but reading frame[0].src is not slide 25

26. Guninski Attack awglogin window.open("https://www.google.com/...") window.open("https://www.attacker.com/...", "awglogin") If bad frame can navigate sibling frames, attacker gets password! slide 26

27. Gadget Hijacking in Mashups top.frames[1].location = "http:/www.attacker.com/... ; top.frames[2].location = "http:/www.attacker.com/... ; ... slide 27

28. Gadget Hijacking Modern browsers only allow a frame to navigate its descendant frames slide 28

29. Features Developed in Response to Guninski Site B Site A u Cross-origin network requests Access-Control-Allow-Origin: <list of domains> Typical usage: Access-Control-Allow-Origin: * - Allowing access to all other origins is not that insecure, since by default, browsers will not send cookies or other authentication info via cross-network requests u Cross-origin client-side communication Client-side messaging via fragment navigation postMessage (HTML5) Site A context Site B context slide 29

30. COMMUNICATION slide 30

31. postMessage u New API for inter-frame communication postMessage(message,targetOrigin) message: string or object sent to target frame targetOrigin: URL of target frame being sent to u Supported in latest browsers slide 31

32. Example of postMessage Usage document.addEventListener("message", receiver); function receiver(e) { if (e.origin == http://a.com") { e.data } } Why is this needed? frames[0].postMessage( Hello! , http://b.com ); b.com a.com c.com Messages are sent to frames, not origins Method invoked on window receiving message See http://blog.teamtreehouse.com/cross-domain-messaging-with-postmessage slide 32

33. Message Eavesdropping (1) frames[0].postMessage( Hello! ) u With descendant frame navigation policy u Attacker replaces inner frame with his own, gets message slide 33

34. Message Eavesdropping (2) frames[0].postMessage( Hello! ) u With any frame navigation policy, even child u Attacker replaces child frame with his own, gets message slide 34

35. But who sent the message? postMessage 2nd parameter specifies the target origin This ensures the message is only sent to targets chosen by the sender The sending origin is revealed to the recipient upon receiving the message, but must be checked slide 35

36. And If The Check Is Wrong? slide 36

37. The Postman Always Rings Twice [Son and Shmatikov] A study of postMessage usage in top 10,000 sites u 2,245 (22%) have a postMessage receiver u 1,585 have a receiver without an origin check u 262 have an incorrect origin check u 84 have exploitable vulnerabilities Received message is evaluated as a script, stored into localStorage, etc. https://www.cs.utexas.edu/~shmat/shmat_ndss13postm an.pdf slide 37