Re: Semi-public resources in Uniform Messaging

On Wed, Dec 9, 2009 at 1:39 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 8 Dec 2009, Tyler Close wrote:
>>
>> I assume you want to move on to the XHR-like example, so I've just got a
>> few clarification questions about it...
>
> The examples are equivalent as far as I can tell. Both are important; for
> me, the <video> one is more important since I'm editing the spec that will
> need to define how to work with <video>.

Since the examples are equivalent, I'll stick to the XHR one for now,
since I'm not sure I fully understand the <video> one yet.

>> On Tue, Dec 8, 2009 at 11:18 AM, Ian Hickson <ian@hixie.ch> wrote:
>> > http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0914/draft.html
>> >
>> > To recast the question in terms of XMLHttpRequest, how would one label a
>> > static resource on an intranet server, e.g.:
>> >
>> >   http://marketing.corp.example.com/productcodes.xml
>> >
>> > ...such that it can be read (using XMLHttpRequest) by scripts embedded on
>> > pages from the following hosts:
>> >
>> >   http://www.corp.example.com/
>> >   http://finance.corp.example.com/
>> >   http://eng.corp.example.com/
>> >   http://intranet.example.com/
>> >
>> > ...but such that it could _not_ be read by pages from the following hosts
>> > (i.e. the HTTP response would not be made accessible to scripts on pages
>> > from these hosts):
>> >
>> >   http://hostile-blog.example.com/
>> >   http://www.hostile.example/
>>
>> Are you saying a firewall prevents the author of the attack pages from
>> directing his own browser to any of the legitimate pages that have
>> access to the data?
>
> I don't think the firewall situation is really relevant, but for the sake
> of argument, let's say that the user is inside the fireall (or on VPN),
> and that *.corp.example.com are only accessible inside the firewall, and
> that intranet.example.com is accessible outside but only through TLS and
> with strong client authentication, and that hostile-blog.example.com and
> www.hostile.example are accessible outside without authentication.

The firewall situation determines whether or not an attacker can
access the secret data directly, rather than via an attack page. I see
that for intranet.example.com, you've replaced the firewall with TLS
and strong client authentication. That should serve the same purpose,
if we assume that no attackers have an account on
intranet.example.com.

>> So, all the resources with access to the secret data are hosted by
>> servers behind a firewall; and all the attackers are outside the
>> firewall?
>
> No.

I assume that's a "no" to the first clause only, since an attacker
behind the firewall has direct access to the secret data. As discussed
in the previous paragraph, you've added TLS and client authentication
to intranet.example.com, so that it can live outside the firewall.

>> Furthermore, all the resources with access to the secret data are
>> trusted to not send the secret data to the attacker?
>
> Yes, the resources who should be able to read the secret data are trusted
> not to send the data to untrusted third parties.
>
>
>> It also seems that any resource hosted behind the firewall also has
>> access to the secret data, since it can just send a request
>> server-to-server, instead of server-to-browser-to-server. True?
>
> In this example, yes, the resource on marketing.corp.example.com is not
> protected from direct access in any way other than via the firewall.

OK, so the whitelist of four sites with access to the data also
implicitly includes all sites behind the firewall.

> A more realistic example would probably have the resource protected from
> direct access by cookie-based authentication, but for the time being I
> think it's simpler to focus on the example without _user_ authentication
> being present also.

Ok, then for this initial simpler case, the simplest UMP solution that
satisfies the stated security constraints is for marketing to put the
product codes at a URL like:

https://marketing.corp.example.com/productcodes/?s=42tjiyrvnbpoal

, where the value of the "s" query string parameter is an unguessable secret.

A GET response from this URL is served with the same-origin opt-out header.

The product code URL is then given to all sites that should have
access to the data. The data display page at these sites starts by
getting a copy of the product code URL. The HTTP response that returns
the product code URL must either be protected by some access-control
mechanism, or not include the same-origin opt-out header. The data
display page can then use an UMP XHR to access the product code data
using the product code URL.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 9 December 2009 15:15:15 UTC