Thank you very much for your answer！ And now I tried to add CURLOPT_UNRESTRICTED_AUTH but it failed. Here are a few examples of what I've tried. 1. docker run -it -e CURLOPT_UNRESTRICTED_AUTH=1 5de1a96efc49 clone http://xxx:xxx@xxx/xxx/xxx 2. echo CURLOPT_UNRESTRICTED_AUTH=1 > $HOME/.curlrc I wonder if it's the way I'm trying to do it wrong Daniel Stenberg <daniel@xxxxxxx> 于2022年8月21日周日 06:32写道： > > On Sat, 20 Aug 2022, Jeff King wrote: > > > The curl change seems to be from 620ea2141 (transfer: redirects to other > > protocols or ports clear auth, 2022-04-25). The goal is to avoid leaking > > credentials between ports: https://curl.se/docs/CVE-2022-27774.html > > > > So that makes sense, though I wonder if curl ought to make an exception > > for moving from 80 to 443 and http to https? > > Nice research there Jeff, and yes this seems entirely correct. > > We stopped curl from following such redirects because of the reasons stated in > the security advisory for that CVE. We quite simply realized that when curl > previously did that, it was actually doing more than what was documented and > what can be considered reasonably safe. > > Following a redirect to another protocol and another port, even if it is still > on the same host name, might very well connect and use another server run by > someone else than the one reached first. We therefore now consider that second > host+port+protocol combo a different host. > > Setting CURLOPT_UNRESTRICTED_AUTH is then the only way to make libcurl send > the credentials again after such a redirect. > > I would not mind having a discussion in the curl project to see if we should > possibly consider adding a middle-ground where we allow sending credentials to > another port for the same host name, but I am personally NOT sold on the idea. > I think such redirects should rather be fixed and avoided - since I believe > users will not understand the security implications of doing them. > > -- > > / daniel.haxx.se
