Hi,

Do you know that Apache HTTP Server and Lighttpd replace non-alnum
characters with underscore in name of environment variables?

This might be useful to bypass restrictions of XMLHttpRequest.

Here is a simple CGI script to test server behavior::

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

import os

print "Content-Type: text/plain\n";

for k, v in sorted(os.environ.items()):
     print "%s: %s" % (k, v)

And execute this script via Apache::

$ telnet localhost 80
GET /~co3k/envs.cgi.py HTTP/1.0
X-Normal: Hello
X_Under: Hello
X.Dot: Hello

HTTP/1.1 200 OK
Date: Wed, 23 Nov 2011 10:30:53 GMT
Server: Apache/2.2.20 (Unix) DAV/2 PHP/5.3.6 with Suhosin-Patch
Connection: close
Content-Type: text/plain

HTTP_X_DOT: Hello
HTTP_X_NORMAL: Hello
HTTP_X_UNDER: Hello

Then, via Lighttpd::

$ telnet localhost 8037
GET /envs.cgi.py HTTP/1.0
X-Normal: Hello
X_Under: Hello
X.Dot: Hello

HTTP/1.0 200 OK
Content-Type: text/plain
Connection: close
Date: Wed, 23 Nov 2011 10:43:12 GMT
Server: lighttpd/1.4.28

HTTP_X_DOT: Hello
HTTP_X_NORMAL: Hello
HTTP_X_UNDER: Hello

But the case of Nginx::

$ telnet localhost 8080
GET /env/ HTTP/1.0
X-Normal: Hello
X_Under: Hello
X.Dot: Hello

HTTP/1.1 200 OK
Server: nginx/1.0.9
Date: Wed, 23 Nov 2011 10:57:07 GMT
Content-Type: text/plain
Connection: close

HTTP_X_NORMAL: Hello

Well, as you know, some XMLHttpRequest implementations deny sending some
request headers via XMLHttpRequest.

(See also:
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest
)

You can't send Accept-Charset, Accept-Encoding, User-Agent, and etc via
Firefox's XMLHttpRequest, but you can send Accept_Charset, Accept.Encoding,
UserAgent and etc. CGI script may trust UserAgent header value via
"HTTP_USER_AGENT" environment variable.

I've found a vulnerability in the Japanese mobile phone by using this
technique. But that vulnerability is caused by unusual custom of Japanese
mobile world.

So I want to know more universal threats by using this technique. Do you
have some ideas?

Thanks,

--
Kousuke Ebihara kousuke@co3k.org
http://co3k.org/

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

-----Original Message-----
From: websecurity-bounces@lists.webappsec.org [mailto:websecurity-
bounces@lists.webappsec.org] On Behalf Of Kousuke Ebihara
Sent: Thursday, January 05, 2012 4:13 AM
To: websecurity@lists.webappsec.org
Subject: [WEB SECURITY] A technique for bypassing request header
restriction of XMLHttpRequest

Hi,

Do you know that Apache HTTP Server and Lighttpd replace non-alnum
characters with underscore in name of environment variables?

This might be useful to bypass restrictions of XMLHttpRequest.

Here is a simple CGI script to test server behavior::

 #!/usr/bin/env python
 # -*- coding: UTF-8 -*-

 import os

 print "Content-Type: text/plain\n";

 for k, v in sorted(os.environ.items()):
      print "%s: %s" % (k, v)

And execute this script via Apache::

 $ telnet localhost 80
 GET /~co3k/envs.cgi.py HTTP/1.0
 X-Normal: Hello
 X_Under: Hello
 X.Dot: Hello

 HTTP/1.1 200 OK
 Date: Wed, 23 Nov 2011 10:30:53 GMT
 Server: Apache/2.2.20 (Unix) DAV/2 PHP/5.3.6 with Suhosin-Patch
 Connection: close
 Content-Type: text/plain

 HTTP_X_DOT: Hello
 HTTP_X_NORMAL: Hello
 HTTP_X_UNDER: Hello

Then, via Lighttpd::

 $ telnet localhost 8037
 GET /envs.cgi.py HTTP/1.0
 X-Normal: Hello
 X_Under: Hello
 X.Dot: Hello

 HTTP/1.0 200 OK
 Content-Type: text/plain
 Connection: close
 Date: Wed, 23 Nov 2011 10:43:12 GMT
 Server: lighttpd/1.4.28

 HTTP_X_DOT: Hello
 HTTP_X_NORMAL: Hello
 HTTP_X_UNDER: Hello

But the case of Nginx::

 $ telnet localhost 8080
 GET /env/ HTTP/1.0
 X-Normal: Hello
 X_Under: Hello
 X.Dot: Hello

 HTTP/1.1 200 OK
 Server: nginx/1.0.9
 Date: Wed, 23 Nov 2011 10:57:07 GMT
 Content-Type: text/plain
 Connection: close

 HTTP_X_NORMAL: Hello

Well, as you know, some XMLHttpRequest implementations deny sending
some request headers via XMLHttpRequest.

(See also: http://code.google.com/p/browsersec/wiki/Part2#Same-
origin_policy_for_XMLHttpRequest)

You can't send Accept-Charset, Accept-Encoding, User-Agent, and etc via
Firefox's XMLHttpRequest, but you can send Accept_Charset,
Accept.Encoding, UserAgent and etc. CGI script may trust UserAgent
header value via "HTTP_USER_AGENT" environment variable.

I've found a vulnerability in the Japanese mobile phone by using this
technique. But that vulnerability is caused by unusual custom of Japanese
mobile world.

So I want to know more universal threats by using this technique. Do you
have some ideas?

Thanks,

--
Kousuke Ebihara kousuke@co3k.org
http://co3k.org/

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.or
g

Hi,

Do you know that Apache HTTP Server and Lighttpd replace non-alnum
characters with underscore in name of environment variables?

This might be useful to bypass restrictions of XMLHttpRequest.

Here is a simple CGI script to test server behavior::

 #!/usr/bin/env python
 # -*- coding: UTF-8 -*-

 import os

 print "Content-Type: text/plain\n";

 for k, v in sorted(os.environ.items()):
      print "%s: %s" % (k, v)

And execute this script via Apache::

 $ telnet localhost 80
 GET /~co3k/envs.cgi.py HTTP/1.0
 X-Normal: Hello
 X_Under: Hello
 X.Dot: Hello

 HTTP/1.1 200 OK
 Date: Wed, 23 Nov 2011 10:30:53 GMT
 Server: Apache/2.2.20 (Unix) DAV/2 PHP/5.3.6 with Suhosin-Patch
 Connection: close
 Content-Type: text/plain

 HTTP_X_DOT: Hello
 HTTP_X_NORMAL: Hello
 HTTP_X_UNDER: Hello

Then, via Lighttpd::

 $ telnet localhost 8037
 GET /envs.cgi.py HTTP/1.0
 X-Normal: Hello
 X_Under: Hello
 X.Dot: Hello

 HTTP/1.0 200 OK
 Content-Type: text/plain
 Connection: close
 Date: Wed, 23 Nov 2011 10:43:12 GMT
 Server: lighttpd/1.4.28

 HTTP_X_DOT: Hello
 HTTP_X_NORMAL: Hello
 HTTP_X_UNDER: Hello

But the case of Nginx::

 $ telnet localhost 8080
 GET /env/ HTTP/1.0
 X-Normal: Hello
 X_Under: Hello
 X.Dot: Hello

 HTTP/1.1 200 OK
 Server: nginx/1.0.9
 Date: Wed, 23 Nov 2011 10:57:07 GMT
 Content-Type: text/plain
 Connection: close

 HTTP_X_NORMAL: Hello

Well, as you know, some XMLHttpRequest implementations deny sending some
request headers via XMLHttpRequest.

(See also:
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest)

You can't send Accept-Charset, Accept-Encoding, User-Agent, and etc via
Firefox's XMLHttpRequest, but you can send Accept_Charset,
Accept.Encoding, UserAgent and etc. CGI script may trust UserAgent
header value via "HTTP_USER_AGENT" environment variable.

I've found a vulnerability in the Japanese mobile phone by using this
technique. But that vulnerability is caused by unusual custom of Japanese
mobile world.

So I want to know more universal threats by using this technique. Do you
have some ideas?

Thanks,

--
Kousuke Ebihara kousuke@co3k.org
http://co3k.org/

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

This is an artifact of the mismatch between the character set available for Unix shell environment variables and those legal in RFC 822 headers as used by HTTP.  The equivalence between at least - and _ is documented in RFC 3875.  http://tools.ietf.org/html/rfc3875#section-4.1.18

So I would expect this bug to be present on all CGI-style applications, and absent in frameworks that provide a better object mapping to HTTP values, e.g. servlets.

Given this is documented and standardized behavior, it seems that the XHR spec should be updated to compare at least "_" and possibly other characters not valid in Unix shell variables, as equivalent to "-" when blacklisting custom headers.

I think given the clearly defined HTTP RFC, we're really looking at age-old
insecure practices in interpreting headers on the web server.
There's no reason that headers with permitted special characters shouldn't
be accessible through an appropriate API.  No good reason to continue
squashing and polluting the namespace.

[Hill, Brad] I would say the opposite.  Given a documented, common practice that, however hacky, has been established for nearly 20 years, there is every reason for a new technology (or at least, relatively new) not to introduce vulnerabilities to a huge and established ecosystem.

I'm not saying XHR should actually coerce non-alphanumeric characters down when sending headers - only that the security checks for banned headers should do this for purposes of pre-flight comparison.  There is an obligation not to introduce new vulnerabilities into existing systems, and the "cost" to long-term compatibility with HTTP is very small: the blacklist becomes a set of simple regexes instead of string literals.