Lines Matching +full:data +full:- +full:urls

1 ---
3 SPDX-License-Identifier: curl
4 Title: libcurl-security
7 See-also:
8   - libcurl-thread (3)
10   - All
11 ---
12 <!-- markdown-link-check-disable -->
15 libcurl-security - security considerations when using libcurl
22 powerful library, however, which allows application writers to make trade-offs
24 the right way, you can use libcurl to transfer data pretty safely.
44 line options. Write them to a protected file and use the -K option to avoid
72 does not let snoopers see your password: Digest, CRAM-MD5, Kerberos, SPNEGO or
82 as long as the connection is unauthenticated. There can be a man-in-the-middle
85 Unauthenticated protocols are unsafe. The data that comes back to curl may
86 have been injected by an attacker. The data that curl sends might be modified
109 files from the local filesystem. If the application returns the data back to
111 leverage this to read otherwise forbidden data (e.g.
116 also at risk. A redirect such as **ftp://some-internal-server/private-file** would
117 then return data even when the server is password protected.
120 user running the libcurl application, SCP: or SFTP: URLs could access password
121 or private-key protected resources,
122 e.g. **sftp://user@some-internal-server/etc/passwd**
129 E.g. **http://127.0.0.1/** or **http://intranet/delete-stuff.cgi?delete=all** or
130 **tftp://bootp-server/pc-config-data**
133 CURLOPT_FOLLOWLOCATION(3) and handling redirects itself, sanitizing URLs
144 and CURLOPT_RANGE(3), libcurl sends the headers as-is and does not apply
155 server-side libcurl-using application could then use. E.g. the innocuous URL
162 All the malicious scenarios regarding redirected URLs apply just as well to
163 non-redirected URLs, if the user is allowed to specify an arbitrary URL that
182 possible to exploit by an attacker who then perhaps can "port-scan" the
183 particular hosts - depending on how the application and servers acts.
188 based on numerical IPv4 addresses used in URLs. This is a bad and error-prone
190 specified and libcurl accepts: one to four dot-separated fields using one of
197 like 127.0.0.1 is not sufficient - the equivalent IPv6 addresses **::1**,
201 link-local and site-local that generally should not be accessed by a
202 server-side libcurl-using application. A poorly configured firewall installed
203 in a data center, organization or server may also be configured to limit IPv4
238 **http://mail.example.com/delete-stuff.cgi?delete=all** Applications can
241 # Dangerous SCP URLs
243 SCP URLs can contain raw commands within the scp: URL, which is a side effect
248 Applications must not allow unsanitized SCP: URLs to be passed in for
253 By default curl and libcurl support file:// URLs. Such a URL is always an
255 avoid that, keep control of what URLs to use and/or prevent curl/libcurl from
258 By default, libcurl prohibits redirects to file:// URLs.
269 networks etc. This resulted in CVE-2019-15601 and the associated security fix.
278 protect users against. It would just be a whack-a-mole race we do not want to
293 If your curl-using script allow a custom URL do you also, perhaps
301 application. Also, cross-protocol operations might be done by using a
303 on a non-standard port.
307 ## Use --proto
309 curl command lines can use *--proto* to limit what URL schemes it accepts
317 Maybe just let the user provide data for parts of it? Or maybe filter input to
322 curl supports URLs mostly according to how they are defined in RFC 3986, and
327 This deviance makes some URLs copied between browsers (or returned over HTTP
329 an application parses URLs differently from libcurl and makes different
334 curl_url(3) API to parse URLs, ensuring that they are parsed the same way
340 up the transfer and one for the actual data.
343 also a weak spot. The second connection to use for data, is either setup with
349 man-in-the-middle or that there is a malicious server pretending to be the
355 Distributed Denial-Of-Service attack out of it. If the client makes an upload
356 operation, it can make the client send the data to another site. If the
357 attacker can affect what data the client uploads, it can be made to work as a
371 address of your local IP to the remote server - even when for example using a
376 A malicious server could cause libcurl to effectively hang by sending data
377 slowly, or even no data at all but just keeping the TCP connection open. This
378 could effectively result in a denial-of-service attack. The
382 A malicious server could cause libcurl to download an infinite amount of data,
386 amount of data received within the write or progress callback and abort once
390 denial-of-service. This can be mitigated by using the
395 User-supplied data must be sanitized when used in options like
398 data. Characters like embedded carriage returns or ampersands could allow the
402 # Server-supplied Names
404 A server can supply data which the application may, in some cases, use as a
405 filename. The curl command-line tool does this with *--remote-header-name*,
406 using the Content-disposition: header to generate a filename. An application
408 server-supplied redirect URL. Special care must be taken to sanitize such
431 security-related data. Besides the obvious candidates like usernames and
432 passwords, things like URLs, cookies or even filenames could also hold
433 sensitive data.
436 can just edit out the sensitive data or just search/replace your true
437 information with faked data.
441 libcurl-using applications that set the 'setuid' bit to run with elevated or
466 When applications pass usernames, passwords or other sensitive data to
467 libcurl to be used for upcoming transfers, those secrets are kept around as-is
472 core dump file, such data might be accessible.
476 credentials may be left in freed data.