Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Custom headers missing in requests to Django

Context: I've written a Django app which I have now deployed to Elastic Beanstalk (AWS).

In local development I've been using a custom request header SESSION_TOKEN which I can then access using request.META.get('HTTP_SESSION_TOKEN'). In production I'm seeing errors because that header is not accessible (aka it is simply missing in all requests my Django server is seeing).

Additionally my other standard headers are working fine, it is only the custom header that is missing. Note I'm not setting HTTP_AUTHORIZATION, this is not the same issue as Authorization header missing in django rest_framework, is apache to blame?.

What is going wrong? How can I access custom headers on my backend in production?

like image 263
owencm Avatar asked Jul 08 '15 02:07

owencm


1 Answers

Most likely SESSION_TOKEN header is stripped by something. From Django security advisory:

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.

and the most important bit of information:

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.

If you have any custom headers you should use hyphen instead.

like image 176
miki725 Avatar answered Nov 19 '22 02:11

miki725