<for the record, I know this idea is kinda out there but I usually like making dumb suggestions>
Why not hash the auth with a salt and then send H(nonce,auth token) to the server? Thus the server if the auth token is really important can generate them if needed - but the attacker can't easily generate the auth token back from the data in report-uri. imho, this is no worse than suppressing the auth as Brandon proposed. cheers devdatta On 8 June 2010 15:14, Adam Barth <abarth-mozi...@adambarth.com> wrote: > 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 > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
