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 [email protected] https://lists.mozilla.org/listinfo/dev-security
