Abstract: Not all web containers can help developers block hop-by-hop headers, and some containers instead allow developers to customize hop-by-hop headers to achieve a greater degree of flexibility.
This article is shared from the HUAWEI CLOUD community " HTTP Request Forwarding: Hop-by-hop Headers and End-to-end Headers that you may not know ", author: Mayfly and the sea.
Introduction
Recently, I saw the official announcement released by F5, which gave a fix for the authentication bypass vulnerability (CVE-2022-1388). This vulnerability allows an attacker to send undisclosed requests to bypass authentication and take control of the system. By reading the repair plan on the official website, it is found that the repair of this vulnerability is actually related to the improper use of the http request header (as shown in the figure below). When the request is forwarded, if the request header such as "Connection: close" in the figure is not properly handled, the request may fail frequently. Today, let's briefly talk about Hop-by-hop Headers that easily make requests forwarding problems.
HTTP headers in request forwarding
At present, microservices have become a popular webapp deployment mode, and data interaction between multiple microservices is inevitable during deployment. Consider the following request forwarding scenario, where App A may be an authentication server or proxy server written by itself:
App A forwards a request intact to App B, and returns App B's response to the client intact. If App A's code or web container does not do special processing to App B's response header, the above situation is prone to occur: the response header contains two headers with the same key value: Connection: someValue.
Since the Connection field in the response header determines whether the HTTP long-term connection is available, when the values of the two Connection fields in the sample are different, the client cannot clearly distinguish the server's attitude towards the current HTTP connection after receiving the request, which will lead to some inconsistencies. foreseen situation. For example, if valueA is "Close" and valueB is "Keep-Alive", the client cannot clearly know whether the server will continue to maintain the current http connection at this time.
In RFC 2612 , the response headers are divided into End-to-end Headers and Hop-by-hop Headers. Hop-by-hop Headers often affect the client's connection maintenance and content processing strategy for http responses. The Connection field is A Hop-by-hop Headers as defined by RFC 2612.
As shown in the figure, RFC 2612 gives the response headers in HTTP/1.1 and explains Hop-by-hop Headers: The response headers in Hop-by-hop Headers are meaningful for a connection, however, these response headers should not be Caching or layer-by-layer forwarding. Conversely, it is understood that the above response headers are forwarded layer by layer, and the request may have problems.
An example of Transfer-Encoding being forwarded
As shown in the figure, when App B has a chunked response, the Transfer-Encoding response header will remind App A to perform chunked reading. Specifically, App B's response body contains Transfer-Encoding: chunked. After App A finds this response header, it will read several response chunks when reading the response body. Read a chunk size, then read chunks. When App A carries Transfer-Encoding: chunked back to the client, the client will try to read App A's response according to the operation of understanding the chunked response. However, using curl will print such information, which means that App A does not have Chunked the response content:
When the containers of App A and App B are tomcat or spring boot, it is easy to reproduce this scenario, but it is not easy to reproduce this problem when App A uses jetty as the container. This shows that some web containers have different processing strategies for Hop-by-hop headers.
Summarize:
Not all web containers help developers block hop-by-hop headers, and some containers instead allow developers to customize hop-by-hop headers for a greater degree of flexibility.
When dealing with request forwarding scenarios, developers should be very careful with such headers, try to use or block these headers as much as possible, and need to perform necessary tests when replacing web containers.
References
[1] Vulnerabilities announced by F5: https://support.f5.com/csp/article/K23605346#proc3
[2]Abusing HTTP hop-by-hop request headers: https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers
[3]RFC 2612:https://datatracker.ietf.org/doc/html/rfc2616#section-13.5.1
Click Follow to learn about HUAWEI CLOUD's new technologies for the first time~