Hello Nick,
Please see my comments below:
On 04/14/2015 10:41 AM, Nick Kew wrote:
On Tue, 2015-04-14 at 10:09 +0400, George Chelidze wrote:
Hello,
According to the rfc822#section-3.2, SPACE character is not allowed in
the header field name.
"Be liberal in what you accept".
Stripping whitespace between a field name and a colon looks
to me like a reasonable thing to do.
It looks reasonable to me as well, however there are two things:
1. according to http://tools.ietf.org/html/rfc7230#section-3.2.4, we have:
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.
2. according to the http://httpd.apache.org/docs/2.4/env.html, the
header should be dropped:
* A special case are HTTP headers which are passed to CGI scripts and
the like via environment variables (see below). They are converted
to uppercase and only dashes are replaced with underscores; if the
header contains any other (invalid) character, the whole header is
silently dropped. See below
<http://httpd.apache.org/docs/2.4/env.html#fixheader> for a workaround.
Unless you're suggesting
it could somehow become a security issue?
I'll try to explain what seems to be an issue for me:
In a network with mobile subscribers there is a device called GGSN. We
can look at it as an IP gateway for mobile subscribers. In our case, the
vendor of GGSN claims, that their device supports HTTP Header Enrichment
Feature - it can inject an MSISDN (unique mobile subsciber's identity)
header to an HTTP request which is destined to the preconfigured URL
(selfcare portal). In case a fake MSISDN header is sent with a request
from the user equipment (UE), it's dropped on GGSN. They also insist
that their system is developed based on well known standards, and as a
header with SPACE in a field name is not a valid header, it's simply
passed to the server as is without any action.
Suppose the following request has been sent from the UE:
GET /cgi-bin/test.pl HTTP/1.0
Host: hostname.for.self.care.portal
X-MSISDN : 123456
GGSN will ignore this "header" as it's not a valid HTTP header and will
append a header with a real user's identity so at the end of processing
the same request will look like this:
GET /cgi-bin/test.pl HTTP/1.0
Host: hostname.for.self.care.portal
X-MSISDN : 123456
X-MSISDN: 987654321
After the request hits an apache server, an environment for a CGI script
will contain HTTP_X_MSISDN=123456, 987654321 - UE has successfully
injected the header which is an issue.
Is there any reason to not ignore a header with the trailing space in
the field name and pass it to the CGI environment?
Surely rather than ignore it, you'd want to return 400
if you don't accept current behaviour?
I meant is there any good reason for the server to ignore the SPACE in
the header and pass it to the CGI enviroment as if there is no space? I
would expect to return 400 according the first document I specified.
--
George Chelidze
