W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] Client-side database and origins

From: Brady Eidson <beidson@apple.com>
Date: Wed, 3 Oct 2007 12:40:52 -0700
Message-ID: <DEF641E6-FFEE-486C-AF6C-D47BB1B0FF31@apple.com>

On Oct 3, 2007, at 12:32 PM, Ian Hickson wrote:

> On Wed, 3 Oct 2007, Brady Eidson wrote:
>> Even if the page at "http://www.foo.com:80/user1" needs to know the
>> database name and the correct version from http://www.foo.com:80/user2 
>> ",
>> this seems like a glaring security issue.
> Even if we limited it to paths, it would still be possible to access  
> the
> database. Since JavaScript same-origin checks aren't based on paths,  
> you'd
> just need to create an <iframe> to a page under /user2 and then inject
> whatever script you wanted. The injected script would run under the / 
> user2
> origin, and would thus give you access to the database.

Fair enough - I accept that explanation and had already come up with  
that workaround myself.

However, what if the developer at "http://www.foo.com:80/user1"  
creates a database called "Photos", and the user at "http://www.foo.com:80/user2 
" does the same.  They both expect to be able to create their own  
database and not have outside interference, yet for the user who  
visits one page before the other, things will inexplicably fail.

I suppose it's an issue that is allowed by the spec and therefore  
developers should be aware of it and able to workaround it.  However,  
it seems like it would be very polite (and probably reasonably simple)  
to design the spec in a manner that would not allow this conflict.

Received on Wednesday, 3 October 2007 12:40:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC