-
Notifications
You must be signed in to change notification settings - Fork 5
/
index.html
467 lines (424 loc) · 22 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title> COWL: A Confinement System for the Web </title>
<!-- Bootstrap core CSS -->
<link href='https://fonts.googleapis.com/css?family=Open+Sans:300,700,300italic' rel='stylesheet' type='text/css'>
<link href="/css/bootstrap.min.css" rel="stylesheet">
<!-- Custom styles for this template -->
<link href="/css/jumbotron-narrow.css" rel="stylesheet">
<script src="/js/jquery-1.11.0.min.js"></script>
<script src="/js/bootstrap.min.js"></script>
<script src="https://google-code-prettify.googlecode.com/svn/loader/run_prettify.js?skin=desert"></script>
</head>
<body>
<div class="container">
<div class="header">
<ul class="nav nav-pills pull-right" id="tabs">
<li class="active"><a href="#home" data-toggle="tab">Home</a></li>
<li><a href="https://w3c.github.io/webappsec/specs/cowl/">Spec</a></li>
<li><a href="#design" data-toggle="tab">Design</a></li>
<li><a href="#example" data-toggle="tab">Example</a></li>
</ul>
<h3 class="text-muted">COWL: A Confinement System for the Web</h3>
</div>
<div class="tab-content">
<div class="tab-pane active" id="home">
<div class="jumbotron">
<h3>About</h3>
<p>
Modern web applications are conglomerations of JavaScript written by multiple
authors: application developers routinely incorporate code from third-party
libraries, and <i>mashup</i> applications synthesize data and code hosted at different
sites. In current browsers, a web application's developer and user must trust
third-party code in libraries not to leak the user's sensitive information from
within applications. Even worse, in the status quo, the only way to implement
some mashups is for the user to give her login credentials for one site to the
operator of another site. Fundamentally, today's browser security model trades
privacy for flexibility because it lacks a sufficient mechanism for <i>confining
untrusted code</i> once it reads sensitive data.
</p>
<p>
COWL (Confinement with Origin Web Labels) is a robust JavaScript confinement system for modern web
browsers. COWL introduces label-based <a
href="https://en.wikipedia.org/wiki/Mandatory_access_control">mandatory access
control</a> to browsing contexts (pages, iframes, etc.) in a way that is fully
backward-compatible with legacy web content. With COWL,
developers not only can restrict with whom they share
data, but also can impose restrictions on how
their data is disseminated once it is shared. COWL
achieves <i>both</i> flexibility for developers and
privacy for users: it allows code to fetch and share data
as necessary, but once code has read sensitive data, COWL
confines the code by revoking its right to
communicate with unauthorized parties.
</p>
</div>
<div class="col-lg-12">
<!-- <a name="paper"></a> -->
<h3>Learn more</a></h3>
<h4>W3C specification</h4>
<p>
<a href="https://w3c.github.io/webappsec/specs/cowl/">
<img src="images/w3c.jpg"/>
<strong>Confinement with Origin Web Labels.</strong>
</a>
Stefan, D.
[<a href="http://www.w3.org/TR/COWL/">FPWD</a> | <a href="https://github.com/w3c/webappsec/tree/master/specs/cowl/">source</a>]
</p>
<h4>Academic paper</h4>
<p>
<a href="http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecting.pdf">
<img src="images/pdf.png"/>
<strong>Protecting Users by Confining JavaScript with COWL.</strong>
</a>
Stefan, D., Yang, E., Marchenko, P., Russo, A., Herman, D., Karp, B., and Mazières, D.
In the Proceedings of the
<a href="https://www.usenix.org/conference/osdi14">
11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 2014) </a>,
Broomfield, CO, October, 2014.
[<a href="http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecting-slides.pdf">slides</a>
| <a href="http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecting.bib">bibTex</a>]
</p>
<h4>Closely-related work</h4>
<p>
<a href="http://www.scs.stanford.edu/~deian/pubs/heule:2015:the-most.pdf">
<img src="images/pdf.png"/>
<strong>The Most Dangerous Code in the Browser.</strong>
</a>
Heule, S., Rifkin, D., Stefan, D., and Russo, A.
In the Proceedings of the
<a href="https://www.usenix.org/conference/hotos15">
Workshop on Hot Topics in Operating Systems (HotOS)</a>,
Kartause, Ittingen, Switzerland, May, 2015.
[ <a href="http://www.scs.stanford.edu/~deian/pubs/heule:2015:the-most.bib">bibTex</a>
| <a href="http://www.scs.stanford.edu/~deian/pubs/heule:2015:the-most-slides.pdf">slides</a>
]
</p>
<p>
<a href="http://www.scs.stanford.edu/~deian/pubs/heule:2015:ifc-inside.pdf">
<img src="images/pdf.png"/>
<strong>IFC Inside: Retrofitting Languages with Dynamic Information Flow Control.</strong>
</a>
Heule, S., Stefan, D., Yang, E., Mitchell, J., and Russo, A.
In the Proceedings of the
<a href="http://www.etaps.org/index.php/2015/post">
Conference on Principles of Security and Trust (POST)</a>,
London, UK, April, 2015.
[ <a href="http://www.scs.stanford.edu/~deian/pubs/heule:2015:ifc-inside.bib">bibTex</a>
| <a href="http://www.scs.stanford.edu/~deian/pubs/heule:2015:ifc-inside-extended.pdf">extended version</a>
]
</p>
<p>
<a href="http://www.scs.stanford.edu/~deian/pubs/yang:2013:towards.pdf">
<img src="images/pdf.png"/>
<strong>Toward Principled Browser Security</strong>
</a>
Yang, E., Stefan, D., Mitchell, J., Mazières, D., Marchenko, P., and Karp, B.
In the Proceedings of the
<a href="https://www.usenix.org/conference/hotos13">
14th USENIX Workshop on Hot Topics in Operating Systems (HotOS XIV)</a>,
Santa Ana, NM, May, 2013.
[<a href="http://www.scs.stanford.edu/~deian/pubs/yang:2013:towards-slides.pdf">slides</a>
| <a href="http://www.scs.stanford.edu/~deian/pubs/yang:2013:towards.bib">bibTex</a>]
</p>
</div>
<div class="col-lg-12 tab-pane">
<h3>Software</a></h3>
<p>
We have implemented COWL as a new DOM-level API for the
Firefox and Chromium browsers. The preliminary version of
our Firefox COWL implementation is available for download.
<strong>Note:</strong> the implementation is as described in the
paper, not the spec.
<p>
<h4>Binaries</h4>
<ul class="list-unstyled">
<li>
<a href="downloads/linux/firefox-36.0a1.en-US.linux-x86_64.tar.bz2">
<img src="images/linux.png" height="25">
Linux
</a>
[<a href="https://support.mozilla.org/en-US/kb/install-firefox-linux">install instructions</a>]
</li>
<li>
<a href="downloads/osx/firefox-36.0a1.en-US.mac64.dmg">
<img src="images/osx.png" height="25">
OS X
</a>
[<a href="https://support.mozilla.org/en-US/kb/how-download-and-install-firefox-mac">install instructions</a>]
</li>
<li>
<a href="downloads/win/firefox-36.0a1.en-US.win32.zip">
<img src="images/win.png" height="25">
Win-32
</a>
[<a href="https://support.mozilla.org/en-US/kb/how-download-and-install-firefox-windows">install instructions</a>]
</li>
</ul>
</p>
<p>
<h4>Source</h4>
You can access the source on <a href="https://github.com/scslab/cowl">GitHub</a>, or by simply running:
<p>
<pre class="prettyprint lang-bash">
$ git clone https://github.com/scslab/cowl.git
</pre>
</p>
</p>
</div>
<div class="col-lg-12 tab-pane">
<h3>Case-studies</a></h3>
<p>
We have implemented several case-studies. We will upload
them to this page, incrementally, as tutorial-like pages.
For now, checkout:
</p>
<ul class="list-unstyled">
<li>
<a href="/examples/checker"><strong>Case study 0: password strength-checker</strong></a>
</li>
</ul>
</div>
<div class="col-lg-12 tab-pane">
<h3>Press</a></h3>
<ul class="list-unstyled">
<li>
<a href="http://www.popularmechanics.com/technology/security/a16741/browser-extension-security/"><strong>Reminder: Your Browser Extensions Have Absurd Access To Everything You Do Online</strong></a>
by Eric Limer, <em>Popular Mechanics</em>, Aug 4, 2015
</li>
<li>
<a href="http://www.theregister.co.uk/2014/10/07/boffins_build_cowl_web_privacy_system_to_cut_malware_off_at_the_knees/"><strong>Holey? COWL! Boffins build boxes to hold sketchy JavaScript libs</strong></a>
by Iain Thomson, <em>The Register</em>, Oct 7, 2014
</li>
<li>
<a href="http://www.engadget.com/2014/10/06/cowl-web-privacy/"><strong>New web privacy system prevents your data from leaking to other sites</strong></a>
by Jon Fingas, <em>Engadget</em>, Oct 6, 2014
</li>
<li>
<a href="http://www.tomshardware.com/news/web-security-cowl-chromium-firefox,27832.html"><strong>COWL Puts A Firewall Between Your Data And Untrusted Web Code</strong></a>
by Lucian Armascu, <em>tom's HARDWARE</em>, Oct 6, 2014
</li>
<li>
<a href="http://www.networkworld.com/article/2691741/microsoft-subnet/researchers-unveil-cowl-a-new-system-to-protect-surfers-privacy.html"><strong>Researchers unveil COWL, a new system to protect web surfers' privacy</strong></a>
by Ms. Smith, <em>NetworkWorld</em>, Oct 6, 2014
</li>
</ul>
</div>
<div class="col-lg-12">
<h3>About us</a></h3>
<p>COWL is a collaboration among several researchers from
several organizations. We are: </p>
<ul>
<li><a href="http://deian.org">Deian Stefan</a> (UCSD and Intrinsic)</li>
<li><a href="http://www.ezyang.com">Edward Z. Yang</a> (Stanford)</li>
<li><a href="http://stefanheule.com/">Stefan Heule</a> (Stanford)</li>
<li><a href="https://twitter.com/devonrifkin">Devon Rifkin</a> (Intrinsic)</li>
<li>Petr Marchenko (Google)</li>
<li><a href="http://www.cse.chalmers.se/~russo/">Alejandro Russo</a> (Chalmers)</li>
<li><a href="http://www.ccs.neu.edu/home/dherman/">Dave Herman</a> (Mozilla Research)</li>
<li><a href="http://www0.cs.ucl.ac.uk/staff/B.Karp/">Brad Karp</a> (UCL)</li>
<li><a href="http://www.scs.stanford.edu/~dm">David Mazières</a> (Stanford)</li>
<li><a href="http://www.cs.stanford.edu/~jcm">John C. Mitchell</a> (Stanford)</li>
</ul>
</div>
</div>
<div class="tab-pane" id="design">
<div class="col-lg-12">
<h3>Design</h3>
The COWL design naturally extends the existing web security model with three
core primitives on which developers can build privacy-preserving
web services. These primitives are:
</div>
<div class="col-lg-12">
<h4>Labeled contexts</h4>
<p>
Today, developers use <i>contexts</i> (<i>e.g.,</i> tabs, pages, and
iframes) to isolate content from different origins (web sites).
COWL extends contexts with <i>labels</i>, which encode the origins
from which a context has read information.
COWL then uses these labels to restrict how code within a
context communicates: it confines the code to disallow
any communication that would result in leaking an origin's sensitive data.
COWL fits well with existing legacy web sites because it
imposes these restrictions within the framework of
existing discretionary access control (DAC) policies, such as the
<a href="https://en.wikipedia.org/wiki/Same-origin_policy">same-origin policy</a> and
<a href="https://en.wikipedia.org/wiki/Content_Security_Policy">CSP</a>.
</p>
</div>
<div class="col-lg-12">
<h4>Labeled communication</h4>
<p>
To impose restrictions on how third-party code can use sensitive data,
developers can label data before handing it off to a third-party context (<i>e.g.,</i> using <var>postMessage</var>).
When the third-party code later decides to use the data, COWL "taints" its
context's label to confine the executing code.
This approach differs from the status quo, in which the
developer must effectively choose between benefiting from the
functionality of the third-party code or risking the
leaking of the sensitive data.
With COWL, a developer can safely use third-party
libraries by ensuring they are confined once granted
access to sensitive information.
</p>
</div>
<div class="col-lg-12">
<h4>Privileges</h4>
<p>
In today's model, when the browser retrieves a page from https://example.com,
any script within the context for the page is trusted not to violate the
security concerns of https://example.com. This is natural: https://example.com
should be allowed to dictate how its data is disseminated! In COWL, this notion
of <i>trust</i> is made explicit with <i>privileges</i>.
Privileges enable code to act on behalf of a page's origin and thus avoid
becoming confined when reading data sensitive to that origin. Equally importantly,
however, COWL allows code to "drop" its privileges or delegate them to other
trustworthy code. Developers can use this primitive to build
applications that adhere to the <a
href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">principle
of least privilege</a>.
</p>
</div>
<div class="col-lg-12">
<p>
These simple three primitives are amenable to a fast browser layout
engine-level implementation, without any modifications to the
underlying JavaScript engine. Moreover, because they extend already
familiar concepts (<i>e.g.,</i> contexts, postMessage, and
XMLHttpRequest), we believe developers will find them a natural means
for exerting additional control over the privacy of the data they
curate. An example (see link above) illustrates how the COWL API can
be used to confine a third-party password strength-checker library;
our paper details three other common application design patterns.
</p>
</div>
</div>
<div class="tab-pane" id="example">
<div class="col-lg-12">
<!-- <a name="example"></a> -->
<h3>Example: Confining a password strength-checker with COWL</a></h3>
<p>
COWL can be used to build several common types of application securely.
Our paper describes several examples, including an
encrypted document editor, an app that relies on jQuery, a third-party
mashup, and a password strength checker. We will release the code for all of these soon,
but for now let's see how we can confine a third-party library such as
a password strength-checker.
</p>
<p>
Suppose the developer of the page https://example.com wants to use the password strength
checker from http://sketchy.ru/checker.js. Maybe the developers at sketchy.ru are not
malicious, but the developer doesn't trust them to write bug-free code.
Note that the checker may need to communicate with sketchy.ru to fetch data
that it needs to do its job.
(For a more realistic library, <i>e.g.,</i> the syntax highlighter running in this page, this is desirable functionality.)
How does the developer use COWL to ensure that the checker
won't leak a user's password to sketchy.ru or any
other site?
</p>
<div>
<h4> Step 1: load the checker in a new labeled context </h4>
<pre class="prettyprint lang-js">
// In example.com page, create new context:
var checker = new LWorker("http://sketchy.ru/checker.js");
</pre>
An <var>LWorker</var> is a lightweight labeled worker, COWL's
approach to creating cheap labeled contexts. (These are similar to
<a href="https://en.wikipedia.org/wiki/Web_worker">Web Workers</a>,
but labeled and run in the same thread as the parent.)
This code simply creates a new context and starts running the untrusted
checker code in this context.
(<emph>Note:</emph> If you are using the preliminary
release of COWL, to run this code you will need to include
<a href="http://cowl.ws/cowl.js">cowl.js</a> to use the
LWorker API.)
</div>
<div>
<h4> Step 2: register handler to get result</h4>
<pre class="prettyprint lang-js">
// In example.com page, register message handler waiting for result
checker.onmessage = function(result) {
console.log('Password is: ' + result.toString());
};
</pre>
Since all communication between labeled contexts is done by
message passing, we register a handler to be invoked once the
checker sends us the result.
</div>
<div>
<h4> Step 3: send password</h4>
<pre class="prettyprint lang-js">
// Is the password sensitive? Yes, label it with example.com!
var labeledPassword = new LabeledBlob(password, "http://example.com");
// Send the checker the labeled password:
checker.postMessage(labeledPassword);
</pre>
Finally, let's send the checker the password so it can do its job.
Since the password is sensitive, though, we label it with the
origin it's sensitive to: example.com. Now when when the checker
reads the password, it will be confined!
</div>
<div>
<h4> The checker code</h4>
<p>
Our code expects the checker to use message passing. What might
this code look like? Here is one possibility:
</p>
<pre class="prettyprint lang-js">
// In checker.js, register handler waiting for request from parent:
onmessage = function(labeledPass) {
if (doneLoading) {
// Taint contex to preserve privacy or password
COWL.privacyLabel = COWL.privacyLabel.and(labeledPass.privacy);
// Now we can read the password
var password = labeledPass.blob;
// Cannot communicate with sketchy.ru anymore, but can reply to parent:
postMessage(checkStrength(password));
}
};
// .. use XHLHttpRequest to communicate with arbitrary sites
</pre>
This checker code starts out unconfined: it can communicate with arbitrary
web sites to fetch any data it needs.
However, once it has finished doing so (indicated by <var>doneLoading</var>)
and the parent has supplied it the labeled password, it can proceed to check
the strength of the password. Specifically, in the <var>onmessage</var> handler,
the code extracts the password from the labeled blob--at which point COWL
taints the context--and computes the strength with the
<var>checkStrength</var> function.
Once the code has inspected the password COWL confines it, preventing it from
communicating arbitrarily.
The code can, of course, send the containing example.com page the
strength of the password.
</div>
<div>
<h4> Take-away: privacy AND functionality</h4>
Even this simple example illustrates how COWL achieves
two properties that are today generally mutally exclusive:
the password strength checker has the <i>flexibility</i>
to communicate as necessary, but once it actually has
inspected the password, it is thereafter prevented from
communicating arbitrarily so as to
ensure <i>privacy</i>. Today developers can either opt for
functionality by allowing
the checker to communicate arbitrarily (even after reading
sensitive data) or privacy by
disallowing it from communicating at all (or not using the library in the first place).
</div>
<div>
<h4> What's next?</h4>
Checkout the <a href="/examples/checker"><strong>case study</strong></a>
that goes into this password strength-checker example in more detail,
with actual running code.
</div>
</div>
</div>
</div>
</div>
</script>
</body>
</html>