Lines Matching +full:- +full:- +full:enable +full:- +full:sftp

1 ---
3 SPDX-License-Identifier: curl
4 Title: libcurl-security
7 See-also:
8   - libcurl-thread (3)
10   - All
11 Added-in: n/a
12 ---
13 <!-- markdown-link-check-disable -->
16 libcurl-security - security considerations when using libcurl
23 powerful library, however, which allows application writers to make trade-offs
45 line options. Write them to a protected file and use the -K option to avoid
57 For applications that enable .netrc use, a user who manage to set the right
73 does not let snoopers see your password: Digest, CRAM-MD5, Kerberos, SPNEGO or
83 as long as the connection is unauthenticated. There can be a man-in-the-middle
117 also at risk. A redirect such as **ftp://some-internal-server/private-file** would
121 user running the libcurl application, SCP: or SFTP: URLs could access password
122 or private-key protected resources,
123 e.g. **sftp://user@some-internal-server/etc/passwd**
130 E.g. **http://127.0.0.1/** or **http://intranet/delete-stuff.cgi?delete=all** or
131 **tftp://bootp-server/pc-config-data**
145 and CURLOPT_RANGE(3), libcurl sends the headers as-is and does not apply
156 server-side libcurl-using application could then use. E.g. the innocuous URL
164 non-redirected URLs, if the user is allowed to specify an arbitrary URL that
183 possible to exploit by an attacker who then perhaps can "port-scan" the
184 particular hosts - depending on how the application and servers acts.
189 based on numerical IPv4 addresses used in URLs. This is a bad and error-prone
191 specified and libcurl accepts: one to four dot-separated fields using one of
198 like 127.0.0.1 is not sufficient - the equivalent IPv6 addresses **::1**,
202 link-local and site-local that generally should not be accessed by a
203 server-side libcurl-using application. A poorly configured firewall installed
239 **http://mail.example.com/delete-stuff.cgi?delete=all** Applications can
270 networks etc. This resulted in CVE-2019-15601 and the associated security fix.
279 protect users against. It would just be a whack-a-mole race we do not want to
294 If your curl-using script allow a custom URL do you also, perhaps
302 application. Also, cross-protocol operations might be done by using a
304 on a non-standard port.
308 ## Use --proto
310 curl command lines can use *--proto* to limit what URL schemes it accepts
350 man-in-the-middle or that there is a malicious server pretending to be the
356 Distributed Denial-Of-Service attack out of it. If the client makes an upload
372 address of your local IP to the remote server - even when for example using a
379 could effectively result in a denial-of-service attack. The
391 denial-of-service. This can be mitigated by using the
396 User-supplied data must be sanitized when used in options like
403 # Server-supplied Names
406 filename. The curl command-line tool does this with *--remote-header-name*,
407 using the Content-disposition: header to generate a filename. An application
409 server-supplied redirect URL. Special care must be taken to sanitize such
432 security-related data. Besides the obvious candidates like usernames and
442 libcurl-using applications that set the 'setuid' bit to run with elevated or
470 libcurl to be used for upcoming transfers, those secrets are kept around as-is