W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: WebAppSec re-charter status

From: Deian Stefan <deian@cs.stanford.edu>
Date: Sun, 08 Feb 2015 17:49:40 -0800
To: Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>
Cc: Jeffrey Yasskin <jyasskin@google.com>, Mike West <mkwst@google.com>, Wendy Seltzer <wseltzer@w3.org>, David Ross <drx@google.com>, Dan Veditz <dveditz@mozilla.com>, Mounir Lamouri <mlamouri@google.com>, David Baron <dbaron@dbaron.org>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
Message-ID: <878ug7onuz.fsf@cs.stanford.edu>

Hi Martin,

Martin Thomson <martin.thomson@gmail.com> writes:
> Now that this is clearer, I think that I can identify the problem, here:
>> This would allow Web application authors and server operators to share data with untrusted code (e.g., in a mashup scenario, cross-origin iframes) yet impose restrictions on how the code can further share the sensitive data.
> This is, as I understand it, a problem for which there is currently no
> good solution.  The papers I've read on this acknowledge the existence
> of the side channels that are available, but don't have good answers
> on how to address the problem.
> For instance, no solution has been offered to deal with the fact that
> the sandboxed code could peg the CPU in order to exfiltrate data.

You're right, COWL would not prevent malicious code from leaking
sensitive information via covert channels. But, today, when you share
data with untrusted code you have no control over what it can do with
the data---all you can do is decide whether or not you *completely*
trust the code. You're not only trusting it to not be malicious, but you
are trusting it (and the code it relies on) to not have bugs that can
lead to leaks. COWL adds another layer of protection to existing
security model (it is strictly more restricting than the SOP and CSP) to
address this. If an attacker has to resort to using covert channels to
leak data then we've improved the current state, in my opinion.

We've previously discussed exfiltration via covert channels in the
context of CSP [1] and I think the general consensus has been to try to
at least address leaks through _overt_ channels.

Would changing the language address some of your concerns? I would be
happy to use a word other than "untrusted." Or at least tone it down to
say "untrusted, but not malicious." (We should avoid giving people the
impression that they can share sensitive data without any concern.)


[1] https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0047.html
Received on Monday, 9 February 2015 01:50:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC