azure-sdk-for-c: az_http_response_get_next_header must reject invalid header field-names including whitespace between it and the colon
header field-names must only consist of characters that are valid according to https://tools.ietf.org/html/rfc7230#section-3.2.6 All others are considered invalid and should be rejected. This includes having whitespace in between the field-name and the field-value.
// Invalid header field name (with space before colon)
az_span response_span = AZ_SPAN_FROM_STR( //
"HTTP/2.0 205 \r\n"
"header1()<>= : some value\r\n"
"Header2:something\t \r\n"
"\r\n");
az_http_response response = { 0 };
az_result result = az_http_response_init(&response, response_span);
assert_true(result == AZ_OK);
// read a status line
{
az_http_response_status_line status_line = { 0 };
result = az_http_response_get_status_line(&response, &status_line);
assert_true(result == AZ_OK);
}
// read a header1
{
az_pair header = { 0 };
result = az_http_response_get_next_header(&response, &header);
assert_true(result == AZ_OK); // This should have failed
// This is wrong, header names should not contain those characters
assert_true(az_span_is_content_equal(header.key, AZ_SPAN_FROM_STR("header1()<>= ")));
}
The current implementation just scans and skips until we find the first colon, treating all the characters until it as part of the header field-name. This needs validation.
From https://tools.ietf.org/html/rfc7230#section-3.2.4:
No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject any received request message that contains whitespace between a header field-name and colon with a response code of 400 (Bad Request). A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.
cc @vhvb1989
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (14 by maintainers)
First, lets be clear about section 3.2.4 of the RFC states: “A server MUST reject …”. We are building clients; not servers. That being said, we can easily look up each header name/value character to ensure that it is within a valid ranges and if not, error out. So, we should do this. And, we should skip whitespace before/after a header value.
I think we should not make any validation in any direction, either Client to Server or Server to Client.
Also, we rely on the http stack, so I wonder if curl will fail…
And regardless the http stack, if we choose to fail an http request because the response returned with an invalid header, customer still need to see that response. Even if response is not a 200, for whatever response we got from a service, we are responsable to deliver that to customer without alterations or validations on it. Then only thing we validate is range, so we fail if response is bigger than provided buffer.
I agree we need to fix