From: Daniel Stenberg Date: Tue, 13 Feb 2018 13:04:04 +0000 (+0100) Subject: libcurl-security.3: separate file:// section X-Git-Tag: curl-7_59_0~78 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=63f6b3b22077c6fd4a75ce4ceac7258509af412c;p=thirdparty%2Fcurl.git libcurl-security.3: separate file:// section ... just to make it more apparent. Even if it repeats some pieces of information. --- diff --git a/docs/libcurl/libcurl-security.3 b/docs/libcurl/libcurl-security.3 index 185fb6b088..377301ee07 100644 --- a/docs/libcurl/libcurl-security.3 +++ b/docs/libcurl/libcurl-security.3 @@ -208,6 +208,13 @@ of how the SCP protocol is designed. e.g. Applications must not allow unsanitized SCP: URLs to be passed in for downloads. +.SH "file://" +By default curl and libcurl support file:// URLs. Such a URL is always an +access, or attempted access, to a local resource. If your application wants to +avoid that, keep control of what URLs to use and/or prevent curl/libcurl from +using the protocol. + +By default, libcurl prohibits redirects to file:// URLs. .SH "What if the user can set the URL" Applications may find it tempting to let users set the URL that it can work on. That's probably fine, but opens up for mischief and trickery that you as