Jochen Roderburg <roderb...@uni-koeln.de> writes: > OTOH I also saw that the patch as such is not yet complete and does > not yet cover all aspects of the underlying problem. > It seems that setting contentdisposition=on (what I also have > permanently in my wget configuration) circumvents the patch. Not only > when a Content-Disposition header is actually used, just the active > option is sufficient for this.
True. The idea is that --content-disposition automatically enables --trust-server-names. When you use --content-disposition you are implicitly trusting the server about the local name to use for storage. > But further thinking shows that actually the whole contentdisposition > feature has the same vulnerability as the redirect case, this is also > a case where a remote server can set the filename which is locally > used by wget. > > So I think: to make the patch complete trustservernames=off must also > imply contentdisposition=off. > Or you invent another separate option for the contentdisposition case. By default --content-disposition is not used. You can enable just --trust-server-names or --content-disposition, and the latter implies the former as well. Unfortunately I don't see any other solution to this security vulnerabilty, at the price of this backward incompatibility. Cheers, Giuseppe
