[whatwg] some thoughts on sandboxed IFRAMEs

[Adam Barth]

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