On Mon, Sep 26, 2011 at 5:39 PM, Carl Meyer <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/26/2011 06:16 AM, Cal Leeming [Simplicity Media Ltd] wrote: > > Unless you can guarantee that all web application servers/load balancers > > are going to correctly handle the header out of the box (i.e. > > inject/strip where necessary), then there's no way this could be > > "securely" introduced. > > The proposal is not to do anything automatically or by default, but to > require the user to explicitly set what header to look for, with > documentation warning them that they should only do this if they know > that the header is always set by their proxy. > Ah - in that case (is it has to be configured by the user first, and doesn't take any assumptions) then that would be much better). I thought you meant a patch to make this "just work - out of the box". > > I agree with Luke and Paul that support for this should be in core - as > they've discussed, the status quo is in itself a security problem. And > while fixing it with a custom middleware is certainly possible, it > requires monkey-patching the request.is_secure() method. Anytime we have > to tell a sizable percentage of our users "you really should add this > custom code to your project that monkeypatches Django core" it's a > pretty strong signal that core should provide better hooks instead. > > > The reason I say per case basis, is because we've had to implement this > > same middleware ourselves into multiple clients, all of which had to be > > slightly different due to the handling of the SSL header at the load > > balancer. > > Can you be more specific here? The only implementation differences that > I can imagine would be which header is checked, and which value is > expected to indicate SSL vs non-SSL. The proposed hook (currently > implemented in django-secure) already accounts for this variation by > requiring the user to explicitly specify the header and value that > should indicate an SSL request. > Yeah - the thing you mentioned above about forcing the user to configure the exact header tackles this point. The problem I had previously, was that some load balancers don't forcibly send or strip certain SSL offloading headers (such as X-Forwarded-Proto), which could result in the user being able to trick the web application into thinking it's in HTTPS, when it's not. But this isn't an issue if it's "configured on demand". > > Carl > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6AqrMACgkQ8W4rlRKtE2dxmwCfRf+gXWLvm/Bup6r0ySJ0qVVU > luMAmwd5XT98WU/kIWLhbUy8NA3aPy7K > =AS+A > -----END PGP SIGNATURE----- > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
