W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2013

Re: CSP: origin from a URL

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 26 Jun 2013 11:08:21 +0100
Message-ID: <CADnb78jVdBH9nVaHitH61wqUKZwBKx1iv8a9cjVkEoOdhrVydQ@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: WebAppSec WG <public-webappsec@w3.org>
On Wed, Jun 26, 2013 at 5:19 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Tue, Jun 25, 2013 at 3:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> Why does https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#reporting
>> use a different algorithm to derive an origin from a URL?
> Different from what?

From: https://tools.ietf.org/html/rfc6454#section-6.2

>> Also, it
>> seems somewhat confusing to have this new origin type, actual origins,
>> and URLs, in the same value space. Even though the property says
>> "blocked-uri" you wouldn't be able to parse it with a URL parser and
>> get a sensible result.
> I'm not sure I understand.  Can you give a specific situation where
> something problematic happens?

Using a URL parser just "data" would fail to parse. It seems the field
is actually a union of schemes, origins, and URLs.

> What we've tried to do with this field is include as much information
> about the blocked URI as we can do safely.  In the same-origin case,
> we can include the URI with the fragment removed.  For the
> cross-origin case, we need to strip out the path and query portions as
> well.  I guess we could do that directly instead of converting to an
> origin and then serializing back to ASCII.  We'd just have to be
> careful to do something sensible with data URIs.

Hmm mkay.

Received on Wednesday, 26 June 2013 10:08:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:33 UTC