Lines Matching refs:to
21 caution and precautions are taken to mitigate many kinds of risks encountered
23 powerful library, however, which allows application writers to make trade-offs
24 between ease of writing and exposure to potential risky operations. If used
25 the right way, you can use libcurl to transfer data pretty safely.
40 options to the tool on the command line those options can get read by other
41 users of your system when they use *ps* or other tools to list currently
44 To avoid these problems, never feed sensitive things to programs using command
45 line options. Write them to a protected file and use the -K option to avoid
50 .netrc is a pretty handy file/feature that allows you to login quickly and
51 automatically to frequently visited sites. The file contains passwords in
57 For applications that enable .netrc use, a user who manage to set the right
58 URL might then be possible to pass on passwords.
67 on your network or a network nearby yours to just fire up a network analyzer
86 Unauthenticated protocols are unsafe. The data that comes back to curl may
93 ## Restrict operations to authenticated transfers
104 redirects sent by a remote server. These redirects can refer to any kind of
105 URL, not just HTTP. libcurl restricts the protocols allowed to be used in
107 enabled by default. Applications may opt to restrict that set further.
109 A redirect to a file: URL would cause the libcurl to read (or write) arbitrary
110 files from the local filesystem. If the application returns the data back to
112 leverage this to read otherwise forbidden data (e.g.
126 used to mitigate against this kind of attack.
142 For all options in libcurl which specify headers, including but not limited to
146 any special sanitation or normalization to them.
149 sequences in them, someone malicious may be able to modify the request in a
155 can change the address of the host to a local, private address which a
157 **http://fuzzybunnies.example.com/** could actually resolve to the IP
163 All the malicious scenarios regarding redirected URLs apply just as well to
164 non-redirected URLs, if the user is allowed to specify an arbitrary URL that
165 could point to a private resource. For example, a web app providing a
171 A malicious FTP server could in response to the PASV command return an IP
172 address and port number for a server local to the app running libcurl but
181 Allowing your application to connect to local hosts, be it the same machine
183 possible to exploit by an attacker who then perhaps can "port-scan" the
188 Some users might be tempted to filter access to local resources or similar
191 specified and libcurl accepts: one to four dot-separated fields using one of
201 to undesired local resources. IPv6 also has special address blocks like
204 in a data center, organization or server may also be configured to limit IPv4
206 CURLOPT_IPRESOLVE(3) to CURL_IPRESOLVE_V4 can be used to limit resolved
207 addresses to IPv4 only and bypass these issues.
211 When uploading, a redirect can cause a local (or remote) file to be
212 overwritten. Applications must not allow any unsanitized URL to be passed in
220 information to be sent to an unknown second server. Applications can mitigate
224 Use of the CURLAUTH_ANY option to CURLOPT_HTTPAUTH(3) could result in username
225 and password being sent in clear text to an HTTP server. Instead, use
229 Use of the CURLUSESSL_TRY option to CURLOPT_USE_SSL(3) could result in
230 username and password being sent in clear text to an FTP server. Instead, use
231 CURLUSESSL_CONTROL to ensure that an encrypted connection is used or else fail
237 performs some malicious action to a site whose authentication is already
249 Applications must not allow unsanitized SCP: URLs to be passed in for
255 access, or attempted access, to a local resource. If your application wants to
256 avoid that, keep control of what URLs to use and/or prevent curl/libcurl from
259 By default, libcurl prohibits redirects to file:// URLs.
264 applications to disable it, to establish a connection to another host over the
268 When first realizing this, the curl team tried to filter out such attempts in
269 order to protect applications for inadvertent probes of for example internal
273 from adequate as there are several other ways to accomplish more or less the
277 The conclusion we have come to is that this is a weakness or feature in the
279 protect users against. It would just be a whack-a-mole race we do not want to
280 participate in. There are too many ways to do it and there is no knob we can
281 use to turn off the practice.
284 FILE protocol in curl or be prepared that accesses to a range of "magic paths"
290 Applications may find it tempting to let users set the URL that it can work
292 an application author may want to address or take precautions against.
295 unintentionally, allow the user to pass other options to the curl command line
298 If the user can set the URL, the user can also specify the scheme part to
299 other protocols that you did not intend for users to use and perhaps did not
303 particular scheme in the URL but point to a server doing a different protocol
310 curl command lines can use *--proto* to limit what URL schemes it accepts
314 libcurl programs can use CURLOPT_PROTOCOLS_STR(3) to limit what URL schemes it accepts
316 ## consider not allowing the user to set the full URL
318 Maybe just let the user provide data for parts of it? Or maybe filter input to
323 curl supports URLs mostly according to how they are defined in RFC 3986, and
326 Web browsers mostly adhere to the WHATWG URL Specification.
332 connecting to the wrong host or otherwise not working identically.
335 curl_url(3) API to parse URLs, ensuring that they are parsed the same way
344 also a weak spot. The second connection to use for data, is either setup with
345 the PORT/EPRT command that makes the server connect back to the client on the
346 given IP+PORT, or with PASV/EPSV that makes the server setup a port to listen
347 to and tells the client to connect to a given IP+PORT.
350 man-in-the-middle or that there is a malicious server pretending to be the
353 A malicious FTP server can respond to PASV commands with the IP+PORT of a
355 many clients trying to connect to that third party, it could create a
357 operation, it can make the client send the data to another site. If the
358 attacker can affect what data the client uploads, it can be made to work as a
359 HTTP request and then the client could be made to issue HTTP requests to third
362 An attacker that manages to control curl's command line options can tell curl
363 to send an FTP PORT command to ask the server to connect to a third party host
364 instead of back to curl.
367 hard to avoid.
371 If you use curl/libcurl to do *active* FTP transfers, curl passes on the
372 address of your local IP to the remote server - even when for example using a
377 A malicious server could cause libcurl to effectively hang by sending data
381 be used to mitigate against this.
383 A malicious server could cause libcurl to download an infinite amount of data,
384 potentially causing system resources to be exhausted resulting in a system or
386 sufficient to guard against this. Instead, applications should monitor the
398 CURLOPT_POSTFIELDS(3) and others that are used to generate structured
400 user to create additional headers or fields that could cause malicious
407 using the Content-disposition: header to generate a filename. An application
408 could also use CURLINFO_EFFECTIVE_URL(3) to generate a filename from a
409 server-supplied redirect URL. Special care must be taken to sanitize such
410 names to avoid the possibility of a malicious server supplying one like
416 option to disable certificate validation. There are numerous attacks that are
417 enabled by applications that fail to properly validate server TLS/SSL
418 certificates, thus enabling a malicious server to spoof a legitimate
425 ask someone for help, everything you reveal in order to get best possible help
427 operating system specifics, etc. (not to mention passwords of course) may in
428 fact be used by intruders to gain additional information of a potential
431 Be sure to limit access to application logs if they could hold private or
442 libcurl-using applications that set the 'setuid' bit to run with elevated or
443 modified rights also implicitly give that extra power to libcurl and this
446 Giving setuid powers to the application means that libcurl can save files using
448 set). Also: if the application wants these powers to read or manage secrets
449 that the user is otherwise not able to view (like credentials for a login
451 variables that allow the user to redirect libcurl operations to use a proxy
460 libcurl itself uses *fork()* and *execl()* if told to use the
469 When applications pass usernames, passwords or other sensitive data to
470 libcurl to be used for upcoming transfers, those secrets are kept around as-is
483 libcurl cannot protect against attacks where an attacker has write access to
484 the same directory where libcurl is directed to save files.
490 allowed to have cookies.
492 if libcurl is *not* built with PSL support, it has no ability to stop super
