[apps-discuss] Discussion Place for CGI/1.1

[Yutaka OIWA <[e-mail]>]

Dear experts in apps-discuss and httpbis,

where should we have talks on CGI/1.1 (RFC 3875), do you think?

# It may propose a small textual addition to httpbis, depending on the
# result of discussions.


A long description of topic is:

I heard of some Japanese discussion on the interfaces and its side-effect
of HTTP/1.1 and CGI/1.1 (RFC 3875, Informational).  It was a security issue,
but the problem itself was not a very interesting thing in context of IETF and a
workaround has been taken, so I'm not in scramble.

When I heard of that, I read RFC 3875.  It translates the names of HTTP headers
to environmental variable names (called in a different name in the spec) in the
following fashion: make it upper-case, replace all hyphens by underscores and
then prepend with "HTTP_".  The original author of CGI spec seems to be defining
the rule as translating "proper" HTTP names (e.g. Forwarded-for) into a
Unix-like good-looking environment variable name (HTTP_FORWARDED_FOR).

However, HTTP/1.1 allows so many "weired" characters in tokens, and the header
names are defined as tokens.  So, "X`Y'Z!" is a valid name for an HTTP header.
Under the current CGI spec, this weired name will result to "HTTP_X`Y'Z!", which
is the thing many people probably think not acceptable for variable name
(including common Unix shell meta characters).

Implementations of CGI/1.1 actually translate all special characters to
underscore, in this example "HTTP_X_Y_Z_".  Some intermediate gateway
did not expect this behavior, and the combination of these has caused
header forging (using X.Y.Z to override existing X-Y-Z header.)

# For curious people: the intermediate was actually a mobile carrier gateway,
# and the forged header was for a mobile device identifier number.
# The gateway removes any occurrence of it and added a proper one.
# Receivers check the source IP address, and if it is in some predefined
# range, they trust the content of such a header.
# Yes, it is really a bad idea, but do not claim its badness on me
# as I know it and it's not my fault :-)
## The gateway was aware of the fact that - and _ will be translated to
## indistinguishable ones in CGI interface.

Strictly following the spec, the web server behavior was against RFC 3875.
However, given the Unix customs and restrictions (which was obviously
the base of CGI specification), the actually-implemented behavior is
more-or-less understandable.  So, what should we do?

Possible solutions are:
  1) to explicitly allow the behavior of current implementations by
     appending rules that non-alnum MAY be translated to underscore.
     By this way, the responsibility will move to the intermediate
     in this case (it should filter out all like X.Y.Z, X!Y%Z, etc).

  2) Appending a text that headers with "weired" characters SHOULD be
     filtered out completely, instead of masking by underscores.
     Existing server implementations to be changed accordingly.
     (Actually, CGI/1.1 already allows some protocol-specific
      filtering of headers, with examples for Authorization-related ones).

  3) Do nothing.  Servers should pass weired characters as is, and
     CGI programmers should take care of that.
     Again, existing server implementations to be changed accordingly,
     and CGI programmers must be really careful to handle these weired things.

  4) Do really nothing: CGI is too old technology (!?) :-)

The solution 1) or 2) may be result as an errata or an update document.
If either 1) or 2) is a good thing, we may also want httpbis to add
a text for future header extensions suggesting that non-alnums except hyphens
are discouraged for any new header specifications.

Original source of problem description along with deployed workaround is in
<http://blog.tokumaru.org/2011/11/kddigw_29.html> in Japanese.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]