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