Proposed addition.
When redirecting it's often useful to redirect to the 'next' url which is
passed from the browser. This variable might be altered before it gets
back to us and so we want to check that the host is a known local host and
approved. Because we don't want this to be checked all the time, it's
optional in the proposed code.
The patch/pull request uses the existing urlparser data to perform the
checks and the placement of the functionality seems like it would make a
good django contribution.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Could you elaborate on the use case for this? Is it intended for mitigate
some attack?
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:1>
Comment (by doctormo):
Yes, so the idea is that there may be a situation where the website needs
to redirect to a url which is assumed to be on the same host. But at the
moment we can't always know if the url that came back from a get/post
request is actually on the same host that the website expects. The url
could have been modified by the client software, sending data and/or the
user to unknown websites.
Form + hidden next variable -> client browser -> our view -> redirect to
next variable.
In that last part, we specify strict_host=True and get the host checking
feature proposed in the delta.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:2>
Comment (by timgraham):
Can you give an example of such a situation? I am still not seeing why
redirecting to a different host might be problematic.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:3>
Comment (by doctormo):
I have given an example. Unsure what the requirement is to convince you. I
don't think this level of resistance is merited in this case.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:4>
Comment (by timgraham):
"there may be a situation where the website needs to redirect to a url
which is assumed to be on the same host" doesn't say why the behavior is
needed. What bad thing could happen without this? That's what I'm trying
to understand.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:5>
Comment (by doctormo):
Sorry for the lack of response Tim, I'm unsure how to answer the question.
The security depends on the web-form being modified, on page or in
transit. So a form that would redirect internally suddenly starts
redirecting out to a spoof website without the user's knowledge or
recognition. Normally the url for redirects is something the server
specifies directly, while links are something the user/client deals with.
The hole here is where the server starts redirecting to other servers even
when not intending to.
One of the questions I think is: Would devs have to monkey patch the
functionality in or write awkward code in order to get this functionality.
Considering the url is already parsed and we have the data ready to check,
it's an ideal place to add the functionality.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:6>
Comment (by timgraham):
I guess I am wondering if this won't give a false sense of security. If an
attacker is in a position to modify the page/URL as you describe, haven't
you already lost? Do you foresee this being a problem for sites that take
basic security measures such as serving pages over SSL to prevent
tampering? Are there other web frameworks that offer the functionality you
are proposing?
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:7>
Comment (by doctormo):
I don't know.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:8>
* status: new => closed
* resolution: => needsinfo
* type: Uncategorized => New feature
Comment:
Closing as "needs info" absent a compelling use case. Seems like you could
write your own `HttpResponseRedirect` subclass to accomplish this if you
want.
--
Ticket URL: <https://code.djangoproject.com/ticket/23330#comment:9>