Let us assume that I have a program on my system which allows third
parties to download any file. The third party specifies a URL, and
(having checked the URL begins http://, https://, ftp:// or ftps://)
my program passes it to curl to download the file. This works well,
and is, I believe, reasonably secure (corrections welcome).

The problem I have is that I want to follow http redirects. If my
program executes curl with the -L switch, following http redirects
works. However, as the user can specify the URL, the possibility
of naughtiness arises. Specifically, I am concerned about them
putting in a (possibly illegal) redirection to a file: URL.

The good news is that if the user specifies a URL on a server under
his own control with the following redirect:
 Redirect 301 /index.htm file:/etc/passwd
this does not work. The bad news is a little manipulation:
 Redirect 301 /index.htm file://etc/etc/passwd
results in a redirect that will cause curl to read and return any
file on the system readable by the curl process.

I would have thought that redirection to file: URLs should be prohibited
anyway. But if not, is there anything one can do to persuade curl to
treat redirects safely?

This seems to be problematic on:
 curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l
zlib/1.2.3
but not on:
 curl 7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k
zlib/1.2.3.3 libidn/1.15
which reports:
 curl: (1) Protocol file not supported or disabled in libcurl

Can I rely on this being fixed in modern versions of curl? IE is curl
/meant/ to prevent this behaviour?

-- 
Alex Bligh
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html