Not to rehash (ha!) a conversation Sid and I already had, but it does seem like hashing each cookie value with a salt might be a useful middle ground. No it won't allow you to recover cookie values the server never logs but does allow you to correlate ids in scenarios like the one Sid mentions below. So for correlation the value could still be there as the various cookie munging mechanisms should be deterministic, assuming you logged all the inputs... though it may require significant additional work to reconstruct.
For other scenarios though, such as when the cookie itself was potentially the source of the attack and/or compromised by the attacker, then it's unlikely you could reconstruct it. I guess the question is which of those scenarios do we really want to address, and does addressing just the former one justify the additional development effort for the utility gained. Seems like just shipping w/o cookies for now might be best and we could try to figure out a better solution later. I'll defer to Brandon and Sid to make that decision tho. Lucas On Jun 11, 2010, at 1:31 PM, Sid Stamm <[email protected]> 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. > >> 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 _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
