On 23/04/2014 19:28, Ryan Sleevi wrote: > On Wed, April 23, 2014 12:15 am, Ivan Ristić wrote: >> According to the HPKP spec: >> >> "If a UA receives more than one PKP header field in an HTTP >> response message over secure transport, then the UA MUST process >> only the first such header field." >> >> What's the rationale for this decision? (The same logic is applied in >> HSTS, so perhaps the behaviour is copied from there?) > > Correct. > >> >> HPKP and HSTS are both vulnerable to response header injection attacks. >> Assuming an application that correctly sets the security headers, a >> successful attack produces a response with multiple security headers and >> the attacker has a good chance to place his headers first. >> >> Have you considered instructing UAs to ignore all headers when there are >> two or more? >> > > The choice here was made explicitly *because* of header injection. > > The disagreement here is whether or not an attacker has a greater chance > of getting their headers to appear first or last. The belief - of both > HPKP and HSTS - is that it is harder, in most web servers (and, for that > matter, scripting languages), for an attacker to get their headers to > appear first. Instead, a webserver is more likely to send any > system-wide/host-wide headers first, and then append any (scripting, > user-specific) headers.
I don't think that's the disagreement. My first point is that this attack vector should be discussed in the RFC, and the decision to use the first PKP header explained. The second (and less important) point is that rejecting HTTP responses with multiple PKP headers might be marginally better than the current behaviour. No matter where the header is injected (first or second), it's never wrong reject both. It certainly feels safer to me; after all we know that that response is contaminated. Further, there'll be a class of attackers who can inject at the first position, but can't inject a double CRLF to perform full HTTP response splitting. For example, the length of the parameter might be limited. -- Ivan _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
