On 6/11/10 1:31 PM, Sid Stamm wrote:
> On 6/11/10 1:19 p, Devdatta wrote:
>> Sid : do you have feedback from developers that this data is
>> absolutely necessary for debugging ? 
> 
> Potentially the data stored in the cookies could control what resources
> are requested by a page, or an attack could otherwise depend on the
> contents of the cookies. The cookie data are useful for debugging the
> same way the URL's querystring is useful.

If the ReportURI is same-origin with the page then we will be
sending all the cookies with the report POST; if it's on the same
eTLD+1 domain we will at least be sending the same domain cookies
with could well be good enough. If the site using CSP needs to
preserve cookies to figure things out why not leave it up to them to
do so rather than risk misdirecting Auth data?

Sure, it's less convenient-- security always is.

> In absence of a good solution, it's probably a
> good idea to avoid sending auth/sensitive headers via the report URI.

I say let's whitelist the headers we do think are useful and drop
everything else. That way we won't get blindsided when HTML 5 or
whoever adds new headers that leak sensitive information. We save a
lot of useless bloat in the reports, too, which admins might thank
us for.

As a start what if we only reported Host, Referer, and Origin?
And maybe the User-Agent in case various CSP client implementations
interpret things differently, although the User-Agent is available
from the report POST itself as well.

-Dan
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to