Is there a single cohesive security model for the web ? No, there is not. What exists today is the result of the original same-origin policy and its evolution in many directions as a response to new threats and attacks. Where did we start, what tools are available to web developers to protect their sites and users, and where might we go in the future as the line between websites and native applications continues to become more and more blurry ? Join us on a journey through the past, present, and future of the web security model and its continuing evolution.

1. The Evolving Web
Security Model
Ian Melven
@imelven
Version 1.1 - Portland OWASP - May 2014
Version 1.0 - BSides Vancouver - March 2013

2. Who is this imelven character ?
* Employed by New Relic in beautiful
Portland, Oregon as an application security
engineer
* Previously worked at Mozilla, Adobe,
Symantec, McAfee, @stake
* I <3 the web and hacking the planet

3. What is the web security model ?
* Is there a single, consistent, unified web
security model ?
* No.
* There are lots of different parts with slightly
different rules
* The web has grown organically, and so has its
security

4. A journey through time and space
* Same Origin Policy
* CORS
* Content Security Policy
* iframe sandbox
* HSTS
* SSL, CA's and cert pinning
* Subresource Integrity (SRI)
* The future : web apps, Service Workers, APIs,
frameworks, site isolation

5. The 'Sort-Of' Same Origin Policy
* first in Netscape Navigator 2 - needed for frames
* scheme://host:port
* Some stuff is accessible cross domain (setting window.
location), some stuff used to be but isn’t now (window.
history), some stuff (cookies) is not truly same origin
* document.domain is weird and sketchy
* Imagine if SOP had been used to check loads - no
mixed content ! (no cross origin content too though.. )

6. XmlHttpRequest and Same Origin
* XHR first in IE 5.0 in 1999 [wikipedia]
* Initially enforced same origin policy
* Web developers started using XHR,
immediately started working around SOP
restriction using proxies
* Major hassle (and possibly insecure)

7. CORS
* Cross Origin Resource Sharing
* Access-Control-Allow-Origin and friends
* Flash Player 7 - crossdomain.xml (2003)
* CORS started as "Authorizing Read Access to
XML Content Using the <?access-control?>
Processing Instruction 1.0" in the W3C in 2005
* W3C candidate recommendation January
2013, also under development in WHATWG
fetch spec
* W3C Recommendation January 16 2014 !

8. Put a CORS on it
* Good tool - can cover new use cases !
* CORS in Canvas - https://developer.mozilla.
org/en-US/docs/HTML/CORS_Enabled_Image
* CORS in webgl - https://hacks.mozilla.
org/2011/11/using-cors-to-load-webgl-
textures-from-cross-domain-images/
bird image : Andreas Plank [CC-BY-SA-3.0]

9. Content Security Policy (CSP)

10. CSP - A Policy To Secure Content
* Basic idea is to restrict where a document
can load various types of content from
* This includes whether inline scripts or the
use of eval() are allowed
* This includes whether styles can be applied
via <style> elements and attributes
* default-src: * ; script-src: unsafe-inline
unsafe-eval ; style-src: unsafe-inline

11. Brief History of CSP : The Idea
* Brandon Sterne drove initial CSP
implementation at Mozilla - he credits
RSnake and Gerv for the idea, and Jeremiah
Grossman for helping make it happen
* The RSnake and Gerv posts describing the
idea are from 2007

12. Brief History of CSP : Towards a
spec
* initial implementation in Firefox 4.0 using
X-Content-Security-Policy - March 2011
* predates the W3C spec which evolved CSP
syntax from this initial first cut
* X-Webkit-CSP in Chrome 13 - August 2011
and Safari 6 (July 2012)
* Working Draft of spec - November 2011

13. Brief History of CSP : 1.0, 1.1 and
beyond
* 1.0 spec became Candidate Recommendation in
November 2012
* Chrome has unprefixed Content-Security-Policy
header support in Chrome 25, Firefox 23, CSP
sandbox support in IE10
* BREAKING : CSP ‘under development’ for IE !
* no need to send both headers or use different
syntaxes !
* CSP 1.1 spec - latest working draft is February
2014 - under development - sticking point seems to
be leakage via reports

14. 20134 - The Year Of The Linux
Desktop CSP
* Isaac Dawson's research (2012) - 79 out of top 1 million
websites serve a CSP header of some kind >:O
* But momentum seems to be building - 2014 update -
355 sites using unprefixed CSP header !
* Libraries : helmet and secureheaders / angular.js
* Tools : proxies, browser addons, generators, more !
* script-nonce & script-hash are in CSP 1.1 and
implemented
* For ideas and strategies on how to roll out CSP in your
org, see me talk about this at https://www.youtube.
com/watch?v=vpKB-yWn79U#t=758

15. CSP - apps and extensions !
* Used by Firefox OS apps, Chrome
extensions, and Chrome apps
* App knows (to a large extent) what content
it needs to load
* Default CSP means apps can’t use risky
things like eval()

16. iframe sandbox
* Bugzilla Bug 341604 - filed 2006 as “implement IE's
"security" attribute for IFRAMEs to help webmail
providers” - became “implement WHATWG iframe
sandbox spec” in 2010
* No plugins, unique origin, no form submission,
different navigation rules (especially for top level
windows), cannot open new windows, no scripts, no
pointer lock
* Can opt back in using allow- keywords
* New keywords not backwards compatible :(

17. The Strange and Wonderful World
of the iframe sandbox
* Widely supported… but anecdotally barely
used ?
* CSP sandbox - what's that about ?
Imagine A.html contains B.html in an iframe - A
sandboxes B - but accessing B directly removes
sandboxing.
* The weirdness of allow-same-origin

18. You got your CSP in my iframe
sandbox
* Both of these mechanisms aim to do the
same thing - restrict what content can do
* Different approaches : CSP much more
granular, sandbox more coarse grained
* iframe CSP attribute ? <meta> CSP is in the
spec ?
* Some sort of CSP JS API ? - debated,
discussed, but nothing yet.

19. HSTS (HTTP Strict Transport
Security)
* ForceHTTPS addon - Collin Jackson, Adam
Barth - 2008
* Original draft spec - Jeff Hodges, Collin
Jackson, Adam Barth - September 2009
* RFC 6797 - published November 2012
* The preload list and problems with it -
https://blog.mozilla.
org/security/2012/11/01/preloading-hsts/
* Preload list is NOT standardized

20. HSTS Quirks
* HSTS is an 'internal' redirect
* Interaction with CSP
* Interaction with mixed content
* HSTS does not allow override per spec
* Not supported in IE currently - but under
development (the trolling worked)

21. SSL/CA system/Certificate Pinning
* SSL/CA system has… issues
* Revocation : CRL -> OCSP -> OCSP stapling /
CRLsets
* Alternate systems : Perspectives,
Convergence, Certificate Transparency
* CA pinning - http://tools.ietf.org/html/draft-
ietf-websec-key-pinning-04
* Pinning preload list - not standardized !

22. Open Questions on Preloads
* How do we maintain a central canonical list
for HSTS and pinning preload ?
* Who should do this ? Who do we trust to do
this ?
* Decentralized, DNS approach - not going to
work here ?

23. Subresource Integrity
* Proposed in 2005 - Gervase Markham’s “Link
Fingerprints” - discussed on WHATWG list through 2006
* New W3C spec - First Public Working Draft 18 March
2014
* SSL authenticates the server but NOT the content
* Use a hash (e.g. SHA-256) to make sure the content
being loaded is exactly what you think it is e.g.
downloads, 3rd party scripts
* Potentially can load content over HTTP, relax mixed
content blocking, etc.

24. The Future : “Web Apps”
* Web apps is an overloaded term - sites (e.g.
gmail) vs packaged apps
* Single page, thick client JS based apps using
Angular and other such frameworks - changes
landscape for content injections, CSRF
protection, etc.
* Packaged web apps - why would you need to
‘install’ a web app ?

25. The Future : Native APIs for Web
Pages
* Scary from a security perspective !
* Not all apps should have access to all apis
* Web pages should not have access to all apis

26. The Future : “Web Apps” Security
Model spec/standard ?
* sysapps WG - began in May 2012 - http://www.w3.
org/2012/sysapps/
* "define a runtime environment, security model, and associated
APIs for building Web applications with comparable capabilities to
native applications.”
* Since v1.0 of this talk, Runtime and Security Model spec has been
abandoned and replaced with App Lifecycle - which covers
installation, etc. but doesn’t talk about permissions or security…
* w3c has a Manifest spec - doesn’t cover permissions - allows
vendor specific extensions (like CSP perhaps ?)

27. The Future : “Web Apps” - Service
Workers
* Service Workers - “event-driven scripts that run
independently of web pages” - can process navigations, do
caching
* The replacement for “much maligned” AppCache - handling
“offline” use of apps
* Must be same origin with the page that installed them
* They handle requests for content on that origin)
* Also can include resources via importScripts() API
* The installing page must be served over HTTPS
* "ServiceWorkers create the opportunity for a bad actor to
turn a bad day into a bad eternity. "

28. The Future : Site Isolation
* Per process site (NOT origin) isolation in
browsers - Chrome has been investigating
this
* Paper: "App Isolation : Get the Security of
Multiple Browsers with Just One"
* IPC performance is critical, more processes
= more memory (think mobile)
* Pretty close to process per installed (web)
app ?

29. The Future : Security conscious
frameworks ?
* Paper: Privilege Separation in HTML5
Applications
* Idea is to use some of the mechanisms
discussed earlier to build web apps with
components of different privilege and a
restricted interface between them
* Sandboxes inside of sandboxes inside of
sandboxes

30. The Cycle of History Continues...
* ‘Web security model’ is constantly evolving as
new attacks are discovered and new
apis/capabilities are added to the web
* The web itself is constantly evolving - Installed
web apps and Angular/single page apps in 2014
vs cgi-bin webmail in the mid 90’s
* What about ‘breaking the web’ ?
* We are making progress ! (I think?) and
recording our learnings in specs/standards,
experimenting and incrementally building

31. To Shape The Future
* There is still much further to go (understatement)
* Browser implementors and standards folk need
feedback from people trying to use these
mechanisms to protect websites or in apps
* What works ? What doesn’t ? what are the pain
points ?
* w3c public-webappsec mailing list, IETF websec
mailing list

32. A Final Thought
[from a 1/8/2013 post to the whatwg list discussing the need to account for
“native” APIs in the html 5 spec’s security model ]
"I suspect we'll need more of that sort of thing as time goes
on.
Which means the security model will likely need to evolve.
Put another way, I think we have good evidence that the
security model in the spec, as well as that in every browser,
Gecko included, is wrong in the same sense that Newtonian
mechanics is wrong. The problem is that we don't know what
our equivalent of special relativity is yet."
- Boris Zbarsky

33. Shout outs
Thank you for attending !
* New Relic Security Team - Shaun Gordon, Adam Kuncewitch, Rafae Bhatti
* Mozilla Security - Sid Stamm, Dan Veditz, Garrett Robinson, David Chan,
Tanvi Vyas, David Keeler, Monica Chew, Camilo Viecco
* Mike West
* Deneb Meketa
* Neil Matatall and the rest of the CSP SuperFriends
* Brad Hill
* Boris Zbarsky
* Everyone working to improve web security in the past, present, and
future
* Andy C, Ed Rush, Optical, Trace

34. Questions ?

35. Resources
https://www.frederik-braun.com/thesis/ Origin Policy
Enforcement in Modern Browsers - A Case Study on Same Origin
Policy Implementations - frederik braun, Ruhr Universitat Bochum
http://www.slideshare.net/BradHill2/w3-conf-
hillhtml5securityrealities - Brad Hill
http://seclab.stanford.edu/websec/origins/fgo.pdf - Beware of
Finer-Grained Origins - Collin Jackson and Adam Barth
http://lcamtuf.coredump.cx/postxss/ - Postcards from the post-
XSS world - Michal Zalewski

36. Resources
http://www.html5rocks.com/en/tutorials/security/content-
security-policy/ - Mike West
http://deadliestwebattacks.files.wordpress.
com/2013/02/javascript-security-html5.pdf - Javascript & HTML5
Security - Mike Shema (BSides SF 2013)
https://mikewest.org/2013/02/securing-the-client-side-devoxx-
2012 - Securing the Client Side - Mike West

37. Resources
http://www.cs.berkeley.
edu/~devdatta/papers/LeastPrivileges.pdf - Privilege
Separation in HTML5 Applications -
Devdatta Akhawe, Prateek Saxena, Dawn Song - UC Berkeley
http://www.html5rocks.
com/en/tutorials/security/sandboxed-iframes/ - Mike West
http://www.cs.berkeley.edu/~afelt/ - Adrienne Porter Felt -
several papers on permissions, particularly on Android

38. Resources
http://www.veracode.com/blog/2012/11/security-headers-
report/ - Security Headers On The Top 1,000,000 Websites -
Isaac Dawson
https://blog.veracode.com/2014/03/security-headers-on-
the-top-1000000-websites-march-2014-report/ - March 2014
update - Isaac Dawson

39. Resources
CSP Tools :
https://github.com/Munter/contentsecure/tree/master/lib
https://addons.mozilla.org/en-
US/firefox/addon/newusercspdesign/
https://github.com/Kennysan/CSPTools
http://lists.w3.org/Archives/Public/public-
webappsec/2014Jan/0075.html

40. Resources
Service Worker spec : https://slightlyoff.github.
io/ServiceWorker/spec/service_worker/index.html
Service Worker “explainer” :
https://github.
com/slightlyoff/ServiceWorker/blob/master/explainer.md
Link Fingerprints - Gervase Markham - http://blog.gerv.
net/2005/03/link_fingerprin_1/
Subresource Integrity spec :
http://www.w3.org/TR/SRI/