Opened 2 years ago

Closed 2 years ago

#23330 closed New feature (needsinfo)

RedirectResponse option to check the host of the url

Reported by: Martin Owens Owned by: nobody
Component: HTTP handling Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (9)

comment:1 Changed 2 years ago by Tim Graham

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

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

comment:2 Changed 2 years ago by 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.

comment:3 Changed 2 years ago by 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.

comment:4 Changed 2 years ago by 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.

comment:5 Changed 2 years ago by 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.

comment:6 Changed 2 years ago by 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.

comment:7 Changed 2 years ago by 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?

comment:8 Changed 2 years ago by Martin Owens

I don't know.

comment:9 Changed 2 years ago by Tim Graham

Resolution: needsinfo
Status: newclosed
Type: UncategorizedNew feature

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

Note: See TracTickets for help on using tickets.
Back to Top