Changes between Initial Version and Version 1 of Ticket #33212, comment 8
- Timestamp:
- Oct 22, 2021, 11:47:29 AM (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33212, comment 8
initial v1 6 6 > One would expect `django_cookie` to have `good_value`. 7 7 8 Why would one expect `django_cookie` to have `good_value`? That example Cookie header is invalid per the specification. As such it should never have existed and the "proper" way would be to simply ignore the header completely. Now the question is how much we'd break w hythat :D I am a bit afraid to do so because in practice django_cookie=" a b c" will probably work well enough through most servers even though it is also invalid.8 Why would one expect `django_cookie` to have `good_value`? That example Cookie header is invalid per the specification. As such it should never have existed and the "proper" way would be to simply ignore the header completely. Now the question is how much we'd break with that :D I am a bit afraid to do so because in practice django_cookie=" a b c" will probably work well enough through most servers even though it is also invalid. 9 9 10 I agree with Collin that changing the order would be a good start to bring us in line with what the rest of the frameworks does -- simply to ensure that a proxy that operates on cookies does not choose the other variant. That said, that proxy/waf should get fixed as well.10 I agree with Collin that changing the order would be a good start to bring us in line with what the rest of the frameworks does -- simply to ensure that a proxy that operates on cookies does not choose the other (majority) variant and leaves us vulnerable. That said, that proxy/waf should get fixed as well. 11 11 12 It is true that this does have security impacts, but an attacker would be able to control the cookie values in interesting ways and in most cases the cookie values don't contain enough interesting material. Even sending two session ids will only cause problems if the proxy before also performs ACL-checks against that session id. But since we never know what this proxy does, we cannot fix it, because the fix might result in a vulnerability in the first place.12 It is true that this does have security impacts, but an attacker would have to be able to control the cookie values and in most cases the cookie values don't contain enough interesting material. Even sending two session ids will only cause problems if the proxy before also performs ACL-checks against that session id. But since we never know what this proxy does, we cannot fix it, because the fix might result in a vulnerability in the first place. 13 13 14 14 Given that most websites seem to be fine with the current behavior I'd be okay to add a strict cookie parsing (and also for set-cookie) behind a setting (as much as I hate settings I expect a non-minimal amount of websites to have invalid cookies). Similar discussion happened on https://code.djangoproject.com/ticket/32191 where Django itself created invalid cookies.