@@ -199,6 +199,17 @@ def log_message(self, format, *args):

sys.stderr.write(msg)

def get_environ(self):

# Strip all headers with underscores in the name before constructing

# the WSGI environ. This prevents header-spoofing based on ambiguity

# between underscores and dashes both normalized to underscores in WSGI

# env vars. Nginx and Apache 2.4+ both do this as well.

for k, v in self.headers.items():

if '_' in k:

del self.headers[k]

return super(WSGIRequestHandler, self).get_environ()

class AdminMediaHandler(handlers.StaticFilesHandler):

"""

@@ -7,6 +7,30 @@ Django 1.4.18 release notes

Django 1.4.18 fixes several security issues in 1.4.17 as well as a regression

on Python 2.5 in the 1.4.17 release.

WSGI header spoofing via underscore/dash conflation

===================================================

When HTTP headers are placed into the WSGI environ, they are normalized by

converting to uppercase, converting all dashes to underscores, and prepending

`HTTP_`. For instance, a header ``X-Auth-User`` would become

``HTTP_X_AUTH_USER`` in the WSGI environ (and thus also in Django's

``request.META`` dictionary).

Unfortunately, this means that the WSGI environ cannot distinguish between

headers containing dashes and headers containing underscores: ``X-Auth-User``

and ``X-Auth_User`` both become ``HTTP_X_AUTH_USER``. This means that if a

header is used in a security-sensitive way (for instance, passing

authentication information along from a front-end proxy), even if the proxy

carefully strips any incoming value for ``X-Auth-User``, an attacker may be

able to provide an ``X-Auth_User`` header (with underscore) and bypass this

protection.

In order to prevent such attacks, both Nginx and Apache 2.4+ strip all headers

containing underscores from incoming requests by default. Django's built-in

development server now does the same. Django's development server is not

recommended for production use, but matching the behavior of common production

servers reduces the surface area for behavior changes during deployment.

Bugfixes

========

@@ -0,0 +1,67 @@

import sys

from django.core.servers.basehttp import WSGIRequestHandler

from django.test import TestCase

from django.utils.six import BytesIO, StringIO

class Stub(object):

def __init__(self, **kwargs):

self.__dict__.update(kwargs)

class WSGIRequestHandlerTestCase(TestCase):

def test_strips_underscore_headers(self):

"""WSGIRequestHandler ignores headers containing underscores.

This follows the lead of nginx and Apache 2.4, and is to avoid

ambiguity between dashes and underscores in mapping to WSGI environ,

which can have security implications.

"""

def test_app(environ, start_response):

"""A WSGI app that just reflects its HTTP environ."""

start_response('200 OK', [])

http_environ_items = sorted(

'%s:%s' % (k, v) for k, v in environ.items()

if k.startswith('HTTP_')

)

yield (','.join(http_environ_items)).encode('utf-8')

rfile = BytesIO()

rfile.write(b"GET / HTTP/1.0\r\n")

rfile.write(b"Some-Header: good\r\n")

rfile.write(b"Some_Header: bad\r\n")

rfile.write(b"Other_Header: bad\r\n")

rfile.seek(0)

# WSGIRequestHandler closes the output file; we need to make this a

# no-op so we can still read its contents.

class UnclosableBytesIO(BytesIO):

def close(self):

pass

wfile = UnclosableBytesIO()

def makefile(mode, *a, **kw):

if mode == 'rb':

return rfile

elif mode == 'wb':

return wfile

request = Stub(makefile=makefile)

server = Stub(base_environ={}, get_app=lambda: test_app)

# We don't need to check stderr, but we don't want it in test output

old_stderr = sys.stderr

sys.stderr = StringIO()

try:

# instantiating a handler runs the request as side effect

WSGIRequestHandler(request, '192.168.0.2', server)

finally:

sys.stderr = old_stderr

wfile.seek(0)

body = list(wfile.readlines())[-1]

self.assertEqual(body, b'HTTP_SOME_HEADER:good')