#26419: Description of ALLOWED_HOSTS confusing
-------------------------------------+-------------------------------------
Reporter: jtpereyda | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Documentation | Version: 1.9
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by jtpereyda:
Old description:
> = Problem =
>
> The documentation has this to say about the purpose of ALLOWED_HOSTS:
>
> This is a security measure to prevent an attacker from poisoning caches
> and triggering password reset emails with links to malicious hosts by
> submitting requests with a fake HTTP Host header, which is possible even
> under many seemingly-safe web server configurations.
>
> For a newcomer, this can be confusing, as evidenced by:
> 1. The necessity of this StackExchange question:
> http://security.stackexchange.com/q/45687/5997 and
> 2. The initial answer's resorting to past release notes for more
> information: http://security.stackexchange.com/a/62313/5997
>
> After further research, I found out that this measure prevents HTTP Host
> Header attacks; detailed write-ups can be found online. Some people
> (including myself) find this post confusing, at least in part because:
>
> 1. The single, long sentence makes it confusing for a newcomer.
> 2. Lack of an attack name makes it hard to learn more.
> 3. Several HTTP Host header attacks are strung together in one
> description, even though not all Host header attacks involve caches or
> password reset emails.
>
> Note that the description is also at least partially imprecise (see point
> 3 above).
>
> = Proposed Solution =
>
> This is a security measure to prevent HTTP Host header attacks, in
> which an attacker uses malicious HTTP Host header values to inject code,
> trigger password reset emails, etc. HTTP Host header attacks can exploit
> the behavior of web applications, web servers, and web caches, even under
> many seemingly-safe web server configurations.
>
> Benefits
> 1. Breaks up description into more compact sentences to decrease "wat?"
> factor.
> 2. Provides name of attack so that users can easily learn more.
> 3. More carefully distinguishes the general purpose (prevent HTTP Host
> header attacks) from specific examples of target (password reset emails)
> and vector (poisoning caches).
> 4. Maintains the "even under many seemingly-safe web serve
> configurations" that will hopefully encourage people to use this feature.
>
> Patch: https://github.com/django/django/pull/6357
New description:
= Problem =
The documentation has this to say about the purpose of ALLOWED_HOSTS:
This is a security measure to prevent an attacker from poisoning caches
and triggering password reset emails with links to malicious hosts by
submitting requests with a fake HTTP Host header, which is possible even
under many seemingly-safe web server configurations.
For a newcomer, this can be confusing, as evidenced by:
1. The necessity of this StackExchange question:
http://security.stackexchange.com/q/45687/5997 and
2. The initial answer's resorting to past release notes for more
information: http://security.stackexchange.com/a/62313/5997
After further research, I found out that this measure prevents HTTP Host
Header attacks; detailed write-ups can be found online. Some people
(including myself) find this post confusing, at least in part because:
1. The single, long sentence makes it confusing for a newcomer.
2. Lack of an attack name makes it hard to learn more.
3. Several HTTP Host header attacks are strung together in one
description, even though not all Host header attacks involve caches or
password reset emails.
Note that the description is also at least partially imprecise (see point
3 above).
= Proposed Solution =
This is a security measure to prevent HTTP Host header attacks, in which
an attacker uses malicious HTTP Host header values to inject code, trigger
password reset emails, etc. HTTP Host header attacks can exploit the
behavior of web applications, web servers, and web caches, even under many
seemingly-safe web server configurations.
Benefits
1. Breaks up description into more compact sentences to decrease "wat?"
factor.
2. Provides name of attack so that users can easily learn more.
3. More carefully distinguishes the general purpose (prevent HTTP Host
header attacks) from specific examples of target (password reset emails)
and vector (poisoning caches).
4. Maintains the "even under many seemingly-safe web serve configurations"
that will hopefully encourage people to use this feature.
= Patch =
https://github.com/django/django/pull/6357
= References =
1. Current documentation:
https://docs.djangoproject.com/en/1.9/ref/settings/#std:setting-
ALLOWED_HOSTS
2. StackExchange question:
http://security.stackexchange.com/questions/45687/what-does-djangos-
allowed-hosts-variable-actually-do/
3. Release notes from original introduction:
https://www.djangoproject.com/weblog/2013/feb/19/security/#s-issue-host-
header-poisoning
4. (It'd be nice to have a link to the discussion or patch that motivated
ALLOWED_HOSTS)
5. Overview of Practical HTTP Host Header attacks, including an
explanation of the Django fix: http://www.skeletonscribe.net/2013/05
/practical-http-host-header-attacks.html
--
--
Ticket URL: <https://code.djangoproject.com/ticket/26419#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.c06d4ada840de95ab046b704b019d75c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
