Opened 2 years ago

Closed 23 months ago

#23330 closed New feature (needsinfo)

RedirectResponse option to check the host of the url

Reported by: doctormo 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


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 timgraham

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

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

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

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

comment:6 Changed 23 months ago 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.

comment:7 Changed 23 months ago 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?

comment:8 Changed 23 months ago by doctormo

I don't know.

comment:9 Changed 23 months ago by timgraham

  • Resolution set to needsinfo
  • Status changed from new to closed
  • Type changed from Uncategorized to New 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