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.

> Could you elaborate with examples ?

Consider this contrived scenario: a cookie could identify a user as a
registered/logged in user and load a bunch of widgets onto a page (this
page doesn't show those widgets for non-authenticated visitors).  A
reflected XSS attack might exploit one of those widgets (and the fact
the user is a specific type of user) to cause a CSRF that posts a bunch
of information to another site using CSRF.

In that scenario the cookies are important because they can help tell
the server admin *why* and *how* the attack was mounted that led to the
CSRF blocked by CSP.

> I am in favor of not sending cookies/auth data right now. After
> deploying CSP, if we hear a lot of complaining that this data is
> absolutely necessary for debugging then we can add it. This, in the
> worst case, would mean that problems for some group of users would be
> hard to debug.

I was hoping someone would post a magic solution to this list that would
let us send cookies.  In absence of a good solution, it's probably a
good idea to avoid sending auth/sensitive headers via the report URI.

> The other way around - deploying with cookies/auth data and finding
> out that it opens a big hole would mean that some group of users would
> be vulnerable - which is not preferable.

Right.  I think most of us are on the same page -- we _really_ don't
want to hose users.  If there's a way around this, though, the extra
session data would be helpful for developers.

-Sid

_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security

Reply via email to