- From: Deian Stefan <deian@cs.stanford.edu>
- Date: Mon, 07 Jul 2014 06:59:35 -0700
- To: Michal Zalewski <lcamtuf@coredump.cx>, pamela fox <pamela.fox@gmail.com>
- Cc: Mike West <mkwst@google.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
- Message-ID: <87vbr946d4.fsf@cs.stanford.edu>
Hi Michal, Michal Zalewski <lcamtuf@coredump.cx> writes: >> I think it's both. If we can prevent the exfiltration of data, we can also >> prevent phishing attacks. > > Well, not per se - you still allow scripts that may ask the users for > their credentials and such; you're just hoping that they won't be able > to hand these over to a remote server or other document, right? > > Unfortunately, the latter, I think, is probably ~impossible :-( > postMessage() is just one example, but there is a multitude of ways > that JavaScript in a sandbox can communicate with the outside world > without navigation or direct requests; for example, it's fairly > straightforward to relay messages by modulating CPU load, by putting > them in window.name or similar places, etc. There have been quite a > few academic papers that hinged on the assumption that such side > channels do not exist or can be suppressed reliably, but I haven't seen > anything that would seem realistic, TBH :-( > > ( In fact, the earliest experiment back in Netscape Navigator days is > probably http://docstore.mik.ua/orelly/web/jscript/ch20_04.html ) I agree that trying to address (certain) covert channels in the browser is not really a practical problem. However, what Pamela is bringing up and what we are also interested in is addressing (some) overt channels. Navigation for sandboxed iframes and postMessage are pretty reasonable things to think about. (In Gecko, and I suspect Blink, even window.name is very much an overt channel.) Moreover, having control over navigation and explicit messaging would serve useful even if only used as a defense-in-depth. (If I am not mistaken, this is how Pamela is also trying to use this.) For postMessage, the proposed message-src attribute would give developers just this, an additional protection layer over the per-call destination-origin argument. If I set a CSP header saying that the only domains I am okay with sending a postMessage to are X, Y, and Z, now I don't need to worry so much about another developer (on my team, but less concerned about security) setting (or rather forgetting to set) the correct destination origin. Cheers, Deian
Received on Monday, 7 July 2014 15:45:57 UTC