W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2012

Re: Removing the same(ish) origin restriction on report-uri

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 29 Feb 2012 14:57:00 -0800
Message-ID: <CAJE5ia9_GOjnbeKfA5ETkE=DBJ6Y4QSj74nR-BkVo1hGqWY2Zg@mail.gmail.com>
To: sec_ext <sec_ext@fb.com>
Cc: "Ware, Ryan R" <ryan.r.ware@intel.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Feb 29, 2012 at 2:53 PM, sec_ext <sec_ext@fb.com> wrote:
> Does this mean the blocked-uri will now be sent by Chrome when a CSP
> violation occurs? I know it was originally stripped due to some privacy
> concerns.

I haven't updated Chrome's implementation yet, but yes.  When I update
it, I'll make it match the spec in this regard.

Note: The spec says:

"If the origin of the blocked-uri is not the same as the document's
origin, then replace the blocked-uri with the ASCII serialization of
the blocked-uri's origin."

That means you'll get the full blocked-uri if it's the same origin as
the document and you'll get the scheme/host/port if its from another
origin.

Adam


> On 2/28/12 5:57 PM, "Ware, Ryan R" <ryan.r.ware@intel.com> wrote:
>
>>On Tue, Feb 28, 2012 at 4:09 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>
>>> On Mon, Feb 27, 2012 at 7:27 PM, Ware, Ryan R <ryan.r.ware@intel.com>
>>> wrote:
>>> > On Tue, Feb 28, 2012 at 10:01 AM, Adam Barth <w3c@adambarth.com>
>>>wrote:
>>> >>
>>> >> I went through all the feedback on CSP violation reports today and
>>> >> made a bunch of edits based on our previous discussions.  I wanted to
>>> >> re-confirm one of those edits with the list:
>>> >>
>>> >> http://dvcs.w3.org/hg/content-security-policy/rev/275074d083aa
>>> >>
>>> >> In that edit, I've removed the restriction that the report-uri needs
>>> >> to have the same scheme, port, and registry-controlled domain as the
>>> >> document-uri.  Originally, we had this restriction because the
>>> >> violation reports contained sensitive information, such as
>>> >> request-headers.  Since then, we've changed the form of the violation
>>> >> reports a bit so that there isn't nearly as much sensitive
>>>information
>>> >> in the reports (which means we can remove the "ugly" dependency on
>>>the
>>> >> public suffix list).
>>> >
>>> >
>>> > Can we get an explicit list of which portions of the reports might
>>>still
>>> > contain sensitive information to better judge if the change is
>>> > appropriate?
>>>
>>> document-uri
>>> -> The address of the protected document, with any <fragment> component
>>> removed
>>>
>>> referrer
>>> -> The referrer attribute of the protected document
>>>
>>> blocked-uri
>>> -> URI of the resource that was prevented from loading due to the
>>> policy violation, with any <fragment> component removed
>>>
>>> violated-directive
>>> -> The policy directive that was violated
>>>
>>> original-policy
>>> -> The original policy as received by the user-agent.
>>>
>>> None of these contain particularly sensitive information, as far as I
>>>can
>>> tell.
>>
>>Thanks Adam.  Given that list I'd concur with your assessment.
>>
>>Ryan
>>
>>> >> This edit seems consistent with our April 2011 discussions on this
>>> >> topic, but since that was a while ago, I wanted to re-confirm with
>>>the
>>> >> list.
>>> >>
>>> >> Thanks!
>>> >> Adam
>>> >>
>>> >
>>
>
Received on Wednesday, 29 February 2012 22:58:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 February 2012 22:58:55 GMT