1. 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
CS 4413/6013: Secure Electronic Commerce Spring 2019
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>
slide 4
Allows Flash object to communicate with external
scripts, navigate frames, open windows

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 (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
protocol://domain:port/path?params
Same Origin Policy
slide 6

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

8. Viewing Cookies in Browser
slide 8

9. Both cookies stored in browser’s cookie
jar,
both are in scope of login.site.com
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
Cookie Identification
slide 9
Cookies are identified by (name, domain, path)

10. domain: any domain suffix of URL-hostname,
except top-level domain (TLD)
Which cookies can be set by login.site.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
allowed domains
login.site.com
.site.com
disallowed domains
user.site.com
othersite.com
.com
SOP for Writing Cookies
slide 10






11. 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
GET //URL-domain/URL-path
Cookie: NAME = VALUE
SOP for Sending Cookies
Browser
Server
slide 11

12. Examples of Cookie SOP
http://checkout.site.com/
http://login.site.com/
https://login.site.com/
cookie 1
name = userid
value = u1
domain = login.site.com
path = /
secure
cookie 2
name = userid
value = u2
domain = .site.com
path = /
non-secure
both set by 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. 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
Who Set The Cookie?
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
slide 15
LSID, GAUSR are
“secure” cookies

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)
• 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
<script type="text/javascript"
src=https://seal.verisign.com/getseal?host_name=A.com>
</script>
slide 18
VeriSign

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
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
<IFRAME SRC="hello.html" WIDTH=450 HEIGHT=100>
If you can see this, your browser doesn't understand IFRAME.
</IFRAME>
slide 20

21. 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
A A
B
B
A
Browser Security Policy for Frames
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 slide 24

25. 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/”
Frame SOP Examples
Navigating child frame is allowed,
but reading frame[0].src is not
slide 25

26. Guninski Attack
window.open("https://www.google.com/...")
window.open("https://www.attacker.com/...", "awglogin")
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
slide 28
Modern browsers only allow a frame to navigate its “descendant” frames

29. Features Developed in
Response to Guninski
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 B
Site A
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 … }
}
slide 32
Messages are sent to frames, not origins
Method invoked on window receiving message
See http://blog.teamtreehouse.com/cross-domain-messaging-with-postmessage
Why is this needed?
frames[0].postMessage(“Hello!”, “http://b.com”);
b.com
a.com
c.com

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?
slide 35
• 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

36. And If The Check Is Wrong?
slide 36

37. The Postman Always Rings Twice
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
[Son and Shmatikov]