- From: Adam Barth <whatwg@adambarth.com>
- Date: Mon, 25 Jan 2010 19:16:27 +0000
On Mon, Jan 25, 2010 at 5:39 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote: > On Mon, Jan 25, 2010 at 1:29 AM, Adam Barth <whatwg at adambarth.com> wrote: >> That depends what information the attacker encodes in the host name. >> Recall that we're imaging the attacker gets to run JavaScript within >> the sandbox > > If we're assuming that, then yes, it's probably hopeless. ?But are we > assuming that? ?The given use-case was webmail -- that would be > expected to disable scripts in the sandbox, no? > >> The point is that stopping exfiltration is a losing battle that we >> shouldn't bother to play. > > Even if scripting is disabled? Blocking exfiltration has a long history on the web. In fact, the first security model for the web, before the same-origin policy, was based on stopping exfiltration. Ultimately, Netscape gave up on that approach and tried the same-origin policy, which is what we're still using today. More recently, there have been some academic papers studying the idea of preventing exfiltration after XSS attacks, including some prototype implementations. None of the implementations I'm aware of have had their security claims stand up to close scrutiny. Of course, none of that means it would be impossible to add a security feature to the web based on blocking exfiltration. If that's something you're passionate about, I'd encourage you to build a prototype system by modifying one of the open source browsers. If you find a clever way of doing that, there are a number of folks in the academic would who would love to hear how. In particular, the Web 2.0 Security & Privacy Workshop might be a good venue to share your findings: http://w2spconf.com/2010/ That venue is particularly inviting to papers written by non-academics. You can see some of the papers from previous years to get a feel for the style, etc. Adam
Received on Monday, 25 January 2010 11:16:27 UTC