On the Security of Parsing Security-Relevant HTTP Headers in Modern Browsers

Web browsers are among the most important but also complex software solutions to access the web. It is therefore not surprising that web browsers are an attractive target for attackers. Especially in the last decade, security researchers and browser vendors have developed sandboxing mechanisms like security-relevant HTTP headers to tackle the problem of getting a more secure browser. Although the security community is aware of the importance of security-relevant HTTP headers, legacy applications and individual requests from different parties have led to possible insecure configurations of these headers. Even if specific security headers are configured correctly, conflicts in their functionalities may lead to unforeseen browser behaviors and vulnerabilities. Recently, the first work which analyzed duplicated headers and conflicts in headers was published by Calzavara et al. at USENIX Security [1]. The authors focused on inconsistent protections by using both, the HTTP header X-Frame-Options and the framing protection of the Content-Security-Policy. We extend their work by analyzing browser behaviors when parsing duplicated headers, conflicting directives, and values that do not conform to the defined ABNF metalanguage specification. We created an open-source testbed running over 19,800 test cases, at which nearly 300 test cases are executed in the set of 66 different browsers. Our work shows that browsers conform to the specification and behave securely. However, all tested browsers behave differently when it comes, for example, to parsing the Strict-Transport-Security header. Moreover, Chrome, Safari, and Firefox behave differently if the header contains a character, which is not allowed by the defined ABNF. This results in the protection mechanism being fully enforced, partially enforced, or not enforced and thus completely bypassable.