RedirectResponse option to check the host of the url

[Martin Owens]

​https://github.com/django/django/pull/3094

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.

[Tim Graham]

Could you elaborate on the use case for this? Is it intended for mitigate some attack?

[Martin Owens]

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.

[Tim Graham]

Can you give an example of such a situation? I am still not seeing why redirecting to a different host might be problematic.

[Martin Owens]

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.

[Tim Graham]

"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.

[Martin Owens]

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.

[Tim Graham]

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?

[Martin Owens]

I don't know.

[Tim Graham]

Closing as "needs info" absent a compelling use case. Seems like you could write your own HttpResponseRedirect subclass to accomplish this if you want.