Another option is to store the report-uri information in the well-known metadata store. Of course, that assumes that the attacker doesn't control the well-known metadata store...
Adam On Tue, Jun 8, 2010 at 3:10 PM, Brandon Sterne <bste...@mozilla.com> wrote: > Hello all, > > I want to bring up an issue that was raised regarding the proposed > report-uri feature of Content Security Policy feature. > > If you assume the following two flaws are present on a legacy server: > 1. Attacker controls the value of the CSP header > 2. A request-processing script on the server which doesn't validate > POST requests it receives but simply places the POST data in a > location accessible to the attacker > > Then CSP introduces a new attack surface that can be used to steal > cookies or other authentication headers. #2 above seems rather > contrived at first blush, but think of a Pastebin-type application that > blindly processes POSTs into publicly available content. (Pastebin > itself is not vulnerable to this attack, since it validates the format > of the POSTs). > > (Note that #1 doesn't require arbitrary HTTP response header injection > or HTTP response splitting. The attacker must control only the value of > the policy header.) > > One we can address this is to suppress the value of any auth headers > that were present in the violation-generating request from the report > POST body. This of course reduces the utility of the reports for server > debugging, but does provide a guarantee that Cookie and related > information won't ever be leaked to attackers through the reports. > > Does this sound like the right approach? > > Cheers, > Brandon > > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
