9

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?

Community
  • 1
  • 1
owencm
  • 8,384
  • 6
  • 38
  • 54

1 Answers1

25

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.

Community
  • 1
  • 1
miki725
  • 27,207
  • 17
  • 105
  • 121
  • 1
    Setting the header in my requests to `Session-Token` and reading them out as `HTTP_SESSION_TOKEN` solved the issue. Thanks! – owencm Jul 08 '15 at 03:31
  • any reason you are not using standard Django's session app which uses a cookie instead of headers to pass session id around. That seems safer since you can specify to use the cookie only in secure connections, etc (not 100% fool-proof but at least its something) – miki725 Jul 08 '15 at 11:15
  • I was originally using Django as an API backend to a native app, so this was the obvious thing to do. I've since switched to building a web client but was worried about CSRF issues with cookies and my current approach was working fine so I kept it :) – owencm Jul 08 '15 at 21:17
  • if you are making API, I would recommend to use a concept of tokens vs session ids. I like to develop APIs using DRF which has token auth built-in - http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication – miki725 Jul 08 '15 at 21:19
  • Thanks for the tip. For what it's worth despite the name `Session-Token` mine are generated with 30 day lifespans and so far as I can tell from reading that doc work the same. Thanks! – owencm Jul 08 '15 at 22:08
  • 2
    I was pulling my hair out because the header wouldn't show up in django, the second part solved my problem, I had underscores in the name – gouravkr Aug 07 '20 at 03:57
  • This is quite a gotcha. Great answer. – TD1 Dec 05 '22 at 20:39