On 23/04/2014 08:42, Yoav Nir wrote: > Hi, Ivan > > Both HPKP and HSTS are only considered when they are received over a > TLS-protected connection. TLS should protect against response header > injection, no?
No, the attack vector here is not transport, but a vulnerable web application. The vulnerability exists whenever an attacker is able to freely inject CRLF sequences into a HTTP response. For example: https://www.example.com/redirect.jsp?target=https://www.example.com/%0d%0aPublic-Key-Pins:%20max-age=0 If the target parameter is used without checking when constructing the Location header in the redirection, the result could be something like: HTTP/1.1 302 Moved Temporarily Some-Header: ... Location: https://www.example.com/ Public-Key-Pins: max-age=0 Other-Headers: ... Public-Key-Pins: max-age=3000; pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; To be fair, an attacker who can do this can also inject a double-CRLF and terminate the HTTP response early, leaving only his PKP response. In other words, this attack vector cannot be fully avoided. Still, being less tolerant to malformed HTTP headers is generally a good thing. I was wondering if there was a reason for doing otherwise. In any case, I think it's worth mentioning this attack in the RFC, so that the risk is understood. Another attack vector that could be described is against the user clock. > Yoav > > On Apr 23, 2014, at 10:15 AM, Ivan Ristić <[email protected]> > 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?) >> >> 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? >> >> -- Ivan >> >> _______________________________________________ websec mailing >> list [email protected] https://www.ietf.org/mailman/listinfo/websec > -- Ivan _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
