diff options
Diffstat (limited to 'docs/libcurl')
| -rw-r--r-- | docs/libcurl/Makefile.inc | 3 | ||||
| -rw-r--r-- | docs/libcurl/libcurl-security.3 | 316 | ||||
| -rw-r--r-- | docs/libcurl/libcurl-tutorial.3 | 231 |
3 files changed, 320 insertions, 230 deletions
diff --git a/docs/libcurl/Makefile.inc b/docs/libcurl/Makefile.inc index 3ac5036ec..eea48c41e 100644 --- a/docs/libcurl/Makefile.inc +++ b/docs/libcurl/Makefile.inc @@ -21,4 +21,5 @@ man_MANS = curl_easy_cleanup.3 curl_easy_getinfo.3 curl_easy_init.3 \ curl_mime_init.3 curl_mime_free.3 curl_mime_addpart.3 curl_mime_name.3 \ curl_mime_data.3 curl_mime_data_cb.3 curl_mime_filedata.3 \ curl_mime_filename.3 curl_mime_subparts.3 \ - curl_mime_type.3 curl_mime_headers.3 curl_mime_encoder.3 libcurl-env.3 + curl_mime_type.3 curl_mime_headers.3 curl_mime_encoder.3 libcurl-env.3 \ + libcurl-security.3 diff --git a/docs/libcurl/libcurl-security.3 b/docs/libcurl/libcurl-security.3 new file mode 100644 index 000000000..63dad5de0 --- /dev/null +++ b/docs/libcurl/libcurl-security.3 @@ -0,0 +1,316 @@ +.\" ************************************************************************** +.\" * _ _ ____ _ +.\" * Project ___| | | | _ \| | +.\" * / __| | | | |_) | | +.\" * | (__| |_| | _ <| |___ +.\" * \___|\___/|_| \_\_____| +.\" * +.\" * Copyright (C) 1998 - 2018, Daniel Stenberg, <daniel@haxx.se>, et al. +.\" * +.\" * This software is licensed as described in the file COPYING, which +.\" * you should have received as part of this distribution. The terms +.\" * are also available at https://curl.haxx.se/docs/copyright.html. +.\" * +.\" * You may opt to use, copy, modify, merge, publish, distribute and/or sell +.\" * copies of the Software, and permit persons to whom the Software is +.\" * furnished to do so, under the terms of the COPYING file. +.\" * +.\" * This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY +.\" * KIND, either express or implied. +.\" * +.\" ************************************************************************** +.\" +.TH libcurl-security 3 "13 Feb 2018" "libcurl" "libcurl security" +.SH NAME +libcurl-security \- security considerations when using libcurl +.SH "Security" +The libcurl project takes security seriously. The library is written with +caution and precautions are taken to mitigate many kinds of risks encountered +while operating with potentially malicious servers on the Internet. It is a +powerful library, however, which allows application writers to make trade-offs +between ease of writing and exposure to potential risky operations. If used +the right way, you can use libcurl to transfer data pretty safely. + +Many applications are used in closed networks where users and servers can +(possibly) be trusted, but many others are used on arbitrary servers and are +fed input from potentially untrusted users. Following is a discussion about +some risks in the ways in which applications commonly use libcurl and +potential mitigations of those risks. It is by no means comprehensive, but +shows classes of attacks that robust applications should consider. The Common +Weakness Enumeration project at https://cwe.mitre.org/ is a good reference for +many of these and similar types of weaknesses of which application writers +should be aware. +.SH "Command Lines" +If you use a command line tool (such as curl) that uses libcurl, and you give +options to the tool on the command line those options can very likely get read +by other users of your system when they use 'ps' or other tools to list +currently running processes. + +To avoid these problems, never feed sensitive things to programs using command +line options. Write them to a protected file and use the \-K option to avoid +this. +.SH ".netrc" +\&.netrc is a pretty handy file/feature that allows you to login quickly and +automatically to frequently visited sites. The file contains passwords in +clear text and is a real security risk. In some cases, your .netrc is also +stored in a home directory that is NFS mounted or used on another network +based file system, so the clear text password will fly through your network +every time anyone reads that file! + +For applications that enable .netrc use, a user who manage to set the right +URL might then be possible to pass on passwords. + +To avoid these problems, don't use .netrc files and never store passwords in +plain text anywhere. +.SH "Clear Text Passwords" +Many of the protocols libcurl supports send name and password unencrypted as +clear text (HTTP Basic authentication, FTP, TELNET etc). It is very easy for +anyone on your network or a network nearby yours to just fire up a network +analyzer tool and eavesdrop on your passwords. Don't let the fact that HTTP +Basic uses base64 encoded passwords fool you. They may not look readable at a +first glance, but they very easily "deciphered" by anyone within seconds. + +To avoid this problem, use an authentication mechanism or other protocol that +doesn't let snoopers see your password: Digest, CRAM-MD5, Kerberos, SPNEGO or +NTLM authentication. Or even better: use authenticated protocols that protect +the entire connection and everything sent over it. +.SH "Un-authenticated Connections" +Protocols that don't have any form of cryptographic authentication can not +with any certainty know that they communicate with the right remote server. + +If your application is using a fixed scheme or fixed host name, it is not safe +as long as the connection is un-authenticated. There can be a +man-in-the-middle or in fact the whole server might have been replaced by an +evil actor. + +Un-authenticated protocols are unsafe. The data that comes back to curl may +have been injected by an attacker. The data that curl sends might be modified +before it reaches the intended server. If it even reaches the intended server +at all. + +Remedies include: + - Restrict operations to authenticated transfers + - Make sure the server's certificate etc is verified +.SH "Redirects" +The \fICURLOPT_FOLLOWLOCATION(3)\fP option automatically follows HTTP +redirects sent by a remote server. These redirects can refer to any kind of +URL, not just HTTP. libcurl restricts the protocols allowed to be used in +redirects for security reasons: FILE, SCP, SMB and SMBS are disabled by +default. Applications are encouraged to restrict that set further. + +A redirect to a file: URL would cause the libcurl to read (or write) arbitrary +files from the local filesystem. If the application returns the data back to +the user (as would happen in some kinds of CGI scripts), an attacker could +leverage this to read otherwise forbidden data (e.g. +file://localhost/etc/passwd). + +If authentication credentials are stored in the ~/.netrc file, or Kerberos +is in use, any other URL type (not just file:) that requires +authentication is also at risk. A redirect such as +ftp://some-internal-server/private-file would then return data even when +the server is password protected. + +In the same way, if an unencrypted SSH private key has been configured for the +user running the libcurl application, SCP: or SFTP: URLs could access password +or private-key protected resources, +e.g. sftp://user@some-internal-server/etc/passwd + +The \fICURLOPT_REDIR_PROTOCOLS(3)\fP and \fICURLOPT_NETRC(3)\fP options can be +used to mitigate against this kind of attack. + +A redirect can also specify a location available only on the machine running +libcurl, including servers hidden behind a firewall from the attacker. +e.g. http://127.0.0.1/ or http://intranet/delete-stuff.cgi?delete=all or +tftp://bootp-server/pc-config-data + +Applications can mitigate against this by disabling +\fICURLOPT_FOLLOWLOCATION(3)\fP and handling redirects itself, sanitizing URLs +as necessary. Alternately, an app could leave \fICURLOPT_FOLLOWLOCATION(3)\fP +enabled but set \fICURLOPT_REDIR_PROTOCOLS(3)\fP and install a +\fICURLOPT_OPENSOCKETFUNCTION(3)\fP callback function in which addresses are +sanitized before use. +.SH "Local Resources" +A user who can control the DNS server of a domain being passed in within a URL +can change the address of the host to a local, private address which a +server-side libcurl-using application could then use. e.g. the innocuous URL +http://fuzzybunnies.example.com/ could actually resolve to the IP address of a +server behind a firewall, such as 127.0.0.1 or 10.1.2.3. Applications can +mitigate against this by setting a \fICURLOPT_OPENSOCKETFUNCTION(3)\fP and +checking the address before a connection. + +All the malicious scenarios regarding redirected URLs apply just as well to +non-redirected URLs, if the user is allowed to specify an arbitrary URL that +could point to a private resource. For example, a web app providing a +translation service might happily translate file://localhost/etc/passwd and +display the result. Applications can mitigate against this with the +\fICURLOPT_PROTOCOLS(3)\fP option as well as by similar mitigation techniques +for redirections. + +A malicious FTP server could in response to the PASV command return an IP +address and port number for a server local to the app running libcurl but +behind a firewall. Applications can mitigate against this by using the +\fICURLOPT_FTP_SKIP_PASV_IP(3)\fP option or \fICURLOPT_FTPPORT(3)\fP. + +Allowing your application to connect to local hosts, be it the same machine +that runs the application or a machine on the same local network, might be +possible to exploit by an attacker who then perhaps can "port-scan" the +particular hosts - depending on how the application and servers acts. +.SH "IPv6 Addresses" +libcurl will normally handle IPv6 addresses transparently and just as easily +as IPv4 addresses. That means that a sanitizing function that filters out +addresses like 127.0.0.1 isn't sufficient--the equivalent IPv6 addresses ::1, +::, 0:00::0:1, ::127.0.0.1 and ::ffff:7f00:1 supplied somehow by an attacker +would all bypass a naive filter and could allow access to undesired local +resources. IPv6 also has special address blocks like link-local and +site-local that generally shouldn't be accessed by a server-side libcurl-using +application. A poorly-configured firewall installed in a data center, +organization or server may also be configured to limit IPv4 connections but +leave IPv6 connections wide open. In some cases, setting +\fICURLOPT_IPRESOLVE(3)\fP to CURL_IPRESOLVE_V4 can be used to limit resolved +addresses to IPv4 only and bypass these issues. +.SH Uploads +When uploading, a redirect can cause a local (or remote) file to be +overwritten. Applications must not allow any unsanitized URL to be passed in +for uploads. Also, \fICURLOPT_FOLLOWLOCATION(3)\fP should not be used on +uploads. Instead, the applications should consider handling redirects itself, +sanitizing each URL first. +.SH Authentication +Use of \fICURLOPT_UNRESTRICTED_AUTH(3)\fP could cause authentication +information to be sent to an unknown second server. Applications can mitigate +against this by disabling \fICURLOPT_FOLLOWLOCATION(3)\fP and handling +redirects itself, sanitizing where necessary. + +Use of the CURLAUTH_ANY option to \fICURLOPT_HTTPAUTH(3)\fP could result in +user name and password being sent in clear text to an HTTP server. Instead, +use CURLAUTH_ANYSAFE which ensures that the password is encrypted over the +network, or else fail the request. + +Use of the CURLUSESSL_TRY option to \fICURLOPT_USE_SSL(3)\fP could result in +user name and password being sent in clear text to an FTP server. Instead, +use CURLUSESSL_CONTROL to ensure that an encrypted connection is used or else +fail the request. +.SH Cookies +If cookies are enabled and cached, then a user could craft a URL which +performs some malicious action to a site whose authentication is already +stored in a cookie. e.g. http://mail.example.com/delete-stuff.cgi?delete=all +Applications can mitigate against this by disabling cookies or clearing them +between requests. +.SH "Dangerous SCP URLs" +SCP URLs can contain raw commands within the scp: URL, which is a side effect +of how the SCP protocol is designed. e.g. + + scp://user:pass@host/a;date >/tmp/test; + +Applications must not allow unsanitized SCP: URLs to be passed in for +downloads. +.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 +an application author may want to address or take precautions against. + +If your curl-using script allow a custom URL do you also, perhaps +unintentionally, allow the user to pass other options to the curl command line +if creative use of special characters are applied? + +If the user can set the URL, the user can also specify the scheme part to +other protocols that you didn't intend for users to use and perhaps didn't +consider. curl supports over 20 different URL schemes. "http://" might be what +you thought, "ftp://" or "imap://" might be what the user gives your +application. Also, cross-protocol operations might be done by using a +particular scheme in the URL but point to a server doing a different protocol +on a non-standard port. + +Remedies: + + - curl command lines can use \fI--proto\fP to limit what schemes it accepts + - libcurl programs can use \fICURLOPT_PROTOCOLS(3)\fP + - consider not allowing the user to set the full URL + - consider strictly filtering input to only allow specific choices +.SH "FTP uses two connections" +When performing an FTP transfer, two TCP connections are used: one for setting +up the transfer and one for the actual data. + +FTP is not only un-authenticated, but the setting up of the second transfer is +also a weak spot. The second connection to use for data, is either setup with +the PORT/EPRT command that makes the server connect back to the client on the +given IP+PORT, or with PASV/EPSV that makes the server setup a port to listen +to and tells the client to connect to a given IP+PORT. + +Again, un-authenticated means that the connection might be meddled with by a +man-in-the-middle or that there's a malicious server pretending to be the +right one. + +A malicious FTP server can respond to PASV commands with the IP+PORT of a +totally different machine. Perhaps even a third party host, and when there are +many clients trying to connect to that third party, it could create a +Distributed Denial-Of-Service attack out of it! If the client makes an upload +operation, it can make the client send the data to another site. If the +attacker can affect what data the client uploads, it can be made to work as a +HTTP request and then the client could be made to issue HTTP requests to third +party hosts. + +An attacker that manages to control curl's command line options can tell curl +to send an FTP PORT command to ask the server to connect to a third party host +instead of back to curl. + +The fact that FTP uses two connections makes it vulnerable in a way that is +hard to avoid. +.SH "Denial of Service" +A malicious server could cause libcurl to effectively hang by sending data +very slowly, or even no data at all but just keeping the TCP connection open. +This could effectively result in a denial-of-service attack. The +\fICURLOPT_TIMEOUT(3)\fP and/or \fICURLOPT_LOW_SPEED_LIMIT(3)\fP options can +be used to mitigate against this. + +A malicious server could cause libcurl to download an infinite amount of data, +potentially causing all of memory or disk to be filled. Setting the +\fICURLOPT_MAXFILESIZE_LARGE(3)\fP option is not sufficient to guard against +this. Instead, applications should monitor the amount of data received within +the write or progress callback and abort once the limit is reached. + +A malicious HTTP server could cause an infinite redirection loop, causing a +denial-of-service. This can be mitigated by using the +\fICURLOPT_MAXREDIRS(3)\fP option. +.SH "Arbitrary Headers" +User-supplied data must be sanitized when used in options like +\fICURLOPT_USERAGENT(3)\fP, \fICURLOPT_HTTPHEADER(3)\fP, +\fICURLOPT_POSTFIELDS(3)\fP and others that are used to generate structured +data. Characters like embedded carriage returns or ampersands could allow the +user to create additional headers or fields that could cause malicious +transactions. +.SH "Server-supplied Names" +A server can supply data which the application may, in some cases, use as a +file name. The curl command-line tool does this with +\fI--remote-header-name\fP, using the Content-disposition: header to generate +a file name. An application could also use \fICURLINFO_EFFECTIVE_URL(3)\fP to +generate a file name from a server-supplied redirect URL. Special care must be +taken to sanitize such names to avoid the possibility of a malicious server +supplying one like "/etc/passwd", "\\autoexec.bat", "prn:" or even ".bashrc". +.SH "Server Certificates" +A secure application should never use the \fICURLOPT_SSL_VERIFYPEER(3)\fP +option to disable certificate validation. There are numerous attacks that are +enabled by applications that fail to properly validate server TLS/SSL +certificates, thus enabling a malicious server to spoof a legitimate +one. HTTPS without validated certificates is potentially as insecure as a +plain HTTP connection. +.SH "Resport Security Problems" +Should you detect or just suspect a security problem in libcurl or curl, +contact the project curl security team immediately. See the separate +SECURITY.md document for details. +.SH "Showing What You Do" +Relatedly, be aware that in situations when you have problems with libcurl and +ask someone for help, everything you reveal in order to get best possible help +might also impose certain security related risks. Host names, user names, +paths, operating system specifics, etc. (not to mention passwords of course) +may in fact be used by intruders to gain additional information of a potential +target. + +Be sure to limit access to application logs if they could hold private or +security-related data. Besides the obvious candidates like user names and +passwords, things like URLs, cookies or even file names could also hold +sensitive data. + +To avoid this problem, you must of course use your common sense. Often, you +can just edit out the sensitive data or just search/replace your true +information with faked data. + diff --git a/docs/libcurl/libcurl-tutorial.3 b/docs/libcurl/libcurl-tutorial.3 index 6b23057de..ab2cbeb99 100644 --- a/docs/libcurl/libcurl-tutorial.3 +++ b/docs/libcurl/libcurl-tutorial.3 @@ -5,7 +5,7 @@ .\" * | (__| |_| | _ <| |___ .\" * \___|\___/|_| \_\_____| .\" * -.\" * Copyright (C) 1998 - 2017, Daniel Stenberg, <daniel@haxx.se>, et al. +.\" * Copyright (C) 1998 - 2018, Daniel Stenberg, <daniel@haxx.se>, et al. .\" * .\" * This software is licensed as described in the file COPYING, which .\" * you should have received as part of this distribution. The terms @@ -1286,234 +1286,7 @@ etc. actually true headers, but in this case we pretend they are! ;-) .SH "Post Transfer Information" - - [ curl_easy_getinfo ] - -.SH "Security Considerations" - -The libcurl project takes security seriously. The library is written with -caution and precautions are taken to mitigate many kinds of risks encountered -while operating with potentially malicious servers on the Internet. It is a -powerful library, however, which allows application writers to make trade offs -between ease of writing and exposure to potential risky operations. If -used the right way, you can use libcurl to transfer data pretty safely. - -Many applications are used in closed networks where users and servers -can be trusted, but many others are used on arbitrary servers and are fed -input from potentially untrusted users. Following is a discussion about -some risks in the ways in which applications commonly use libcurl and -potential mitigations of those risks. It is by no means comprehensive, but -shows classes of attacks that robust applications should consider. The -Common Weakness Enumeration project at https://cwe.mitre.org/ is a good -reference for many of these and similar types of weaknesses of which -application writers should be aware. - -.IP "Command Lines" -If you use a command line tool (such as curl) that uses libcurl, and you give -options to the tool on the command line those options can very likely get read -by other users of your system when they use 'ps' or other tools to list -currently running processes. - -To avoid this problem, never feed sensitive things to programs using command -line options. Write them to a protected file and use the \-K option to -avoid this. - -.IP ".netrc" -\&.netrc is a pretty handy file/feature that allows you to login quickly and -automatically to frequently visited sites. The file contains passwords in -clear text and is a real security risk. In some cases, your .netrc is also -stored in a home directory that is NFS mounted or used on another network -based file system, so the clear text password will fly through your network -every time anyone reads that file! - -To avoid this problem, don't use .netrc files and never store passwords in -plain text anywhere. - -.IP "Clear Text Passwords" -Many of the protocols libcurl supports send name and password unencrypted as -clear text (HTTP Basic authentication, FTP, TELNET etc). It is very easy for -anyone on your network or a network nearby yours to just fire up a network -analyzer tool and eavesdrop on your passwords. Don't let the fact that HTTP -Basic uses base64 encoded passwords fool you. They may not look readable at a -first glance, but they very easily "deciphered" by anyone within seconds. - -To avoid this problem, use an authentication mechanism or other protocol that -doesn't let snoopers see your password: Digest, CRAM-MD5, Kerberos, SPNEGO or -NTLM authentication, HTTPS, FTPS, SCP and SFTP are a few examples. - -.IP "Redirects" -The \fICURLOPT_FOLLOWLOCATION(3)\fP option automatically follows HTTP -redirects sent by a remote server. These redirects can refer to any kind of -URL, not just HTTP. By default libcurl will allow all protocols on redirect -except several disabled for security reasons: Since 7.19.4 FILE and SCP are -disabled, and since 7.40.0 SMB and SMBS are also disabled. - -A redirect to a file: URL would cause the libcurl to read (or write) arbitrary -files from the local filesystem. If the application returns the data back to -the user (as would happen in some kinds of CGI scripts), an attacker could -leverage this to read otherwise forbidden data (e.g. -file://localhost/etc/passwd). - -If authentication credentials are stored in the ~/.netrc file, or Kerberos -is in use, any other URL type (not just file:) that requires -authentication is also at risk. A redirect such as -ftp://some-internal-server/private-file would then return data even when -the server is password protected. - -In the same way, if an unencrypted SSH private key has been configured for -the user running the libcurl application, SCP: or SFTP: URLs could access -password or private-key protected resources, -e.g. sftp://user@some-internal-server/etc/passwd - -The \fICURLOPT_REDIR_PROTOCOLS(3)\fP and \fICURLOPT_NETRC(3)\fP options can be -used to mitigate against this kind of attack. - -A redirect can also specify a location available only on the machine running -libcurl, including servers hidden behind a firewall from the attacker. -e.g. http://127.0.0.1/ or http://intranet/delete-stuff.cgi?delete=all or -tftp://bootp-server/pc-config-data - -Apps can mitigate against this by disabling \fICURLOPT_FOLLOWLOCATION(3)\fP -and handling redirects itself, sanitizing URLs as necessary. Alternately, an -app could leave \fICURLOPT_FOLLOWLOCATION(3)\fP enabled but set -\fICURLOPT_REDIR_PROTOCOLS(3)\fP and install a -\fICURLOPT_OPENSOCKETFUNCTION(3)\fP callback function in which addresses are -sanitized before use. - -.IP "Private Resources" -A user who can control the DNS server of a domain being passed in within a URL -can change the address of the host to a local, private address which a -server-side libcurl-using application could then use. e.g. the innocuous URL -http://fuzzybunnies.example.com/ could actually resolve to the IP address of a -server behind a firewall, such as 127.0.0.1 or 10.1.2.3. Apps can mitigate -against this by setting a \fICURLOPT_OPENSOCKETFUNCTION(3)\fP and checking the -address before a connection. - -All the malicious scenarios regarding redirected URLs apply just as well to -non-redirected URLs, if the user is allowed to specify an arbitrary URL that -could point to a private resource. For example, a web app providing a -translation service might happily translate file://localhost/etc/passwd and -display the result. Apps can mitigate against this with the -\fICURLOPT_PROTOCOLS(3)\fP option as well as by similar mitigation techniques -for redirections. - -A malicious FTP server could in response to the PASV command return an IP -address and port number for a server local to the app running libcurl but -behind a firewall. Apps can mitigate against this by using the -\fICURLOPT_FTP_SKIP_PASV_IP(3)\fP option or \fICURLOPT_FTPPORT(3)\fP. - -.IP "IPv6 Addresses" -libcurl will normally handle IPv6 addresses transparently and just as easily -as IPv4 addresses. That means that a sanitizing function that filters out -addresses like 127.0.0.1 isn't sufficient--the equivalent IPv6 addresses ::1, -::, 0:00::0:1, ::127.0.0.1 and ::ffff:7f00:1 supplied somehow by an attacker -would all bypass a naive filter and could allow access to undesired local -resources. IPv6 also has special address blocks like link-local and site-local -that generally shouldn't be accessed by a server-side libcurl-using -application. A poorly-configured firewall installed in a data center, -organization or server may also be configured to limit IPv4 connections but -leave IPv6 connections wide open. In some cases, the CURL_IPRESOLVE_V4 option -can be used to limit resolved addresses to IPv4 only and bypass these issues. - -.IP Uploads -When uploading, a redirect can cause a local (or remote) file to be -overwritten. Apps must not allow any unsanitized URL to be passed in for -uploads. Also, \fICURLOPT_FOLLOWLOCATION(3)\fP should not be used on uploads. -Instead, the app should handle redirects itself, sanitizing each URL first. - -.IP Authentication -Use of \fICURLOPT_UNRESTRICTED_AUTH(3)\fP could cause authentication -information to be sent to an unknown second server. Apps can mitigate against -this by disabling \fICURLOPT_FOLLOWLOCATION(3)\fP and handling redirects -itself, sanitizing where necessary. - -Use of the CURLAUTH_ANY option to \fICURLOPT_HTTPAUTH(3)\fP could result in -user name and password being sent in clear text to an HTTP server. Instead, -use CURLAUTH_ANYSAFE which ensures that the password is encrypted over the -network, or else fail the request. - -Use of the CURLUSESSL_TRY option to \fICURLOPT_USE_SSL(3)\fP could result in -user name and password being sent in clear text to an FTP server. Instead, -use CURLUSESSL_CONTROL to ensure that an encrypted connection is used or else -fail the request. - -.IP Cookies -If cookies are enabled and cached, then a user could craft a URL which -performs some malicious action to a site whose authentication is already -stored in a cookie. e.g. http://mail.example.com/delete-stuff.cgi?delete=all -Apps can mitigate against this by disabling cookies or clearing them -between requests. - -.IP "Dangerous URLs" -SCP URLs can contain raw commands within the scp: URL, which is a side effect -of how the SCP protocol is designed. e.g. -scp://user:pass@host/a;date >/tmp/test; -Apps must not allow unsanitized SCP: URLs to be passed in for downloads. - -.IP "Denial of Service" -A malicious server could cause libcurl to effectively hang by sending a -trickle of data through, or even no data at all but just keeping the TCP -connection open. This could result in a denial-of-service attack. The -\fICURLOPT_TIMEOUT(3)\fP and/or \fICURLOPT_LOW_SPEED_LIMIT(3)\fP options can -be used to mitigate against this. - -A malicious server could cause libcurl to effectively hang by starting to send -data, then severing the connection without cleanly closing the TCP connection. -The app could install a \fICURLOPT_SOCKOPTFUNCTION(3)\fP callback function and -set the TCP SO_KEEPALIVE option to mitigate against this. Setting one of the -timeout options would also work against this attack. - -A malicious server could cause libcurl to download an infinite amount of data, -potentially causing all of memory or disk to be filled. Setting the -\fICURLOPT_MAXFILESIZE_LARGE(3)\fP option is not sufficient to guard against -this. Instead, the app should monitor the amount of data received within the -write or progress callback and abort once the limit is reached. - -A malicious HTTP server could cause an infinite redirection loop, causing a -denial-of-service. This can be mitigated by using the -\fICURLOPT_MAXREDIRS(3)\fP option. - -.IP "Arbitrary Headers" -User-supplied data must be sanitized when used in options like -\fICURLOPT_USERAGENT(3)\fP, \fICURLOPT_HTTPHEADER(3)\fP, -\fICURLOPT_POSTFIELDS(3)\fP and others that are used to generate structured -data. Characters like embedded carriage returns or ampersands could allow the -user to create additional headers or fields that could cause malicious -transactions. - -.IP "Server-supplied Names" -A server can supply data which the application may, in some cases, use as -a file name. The curl command-line tool does this with --remote-header-name, -using the Content-disposition: header to generate a file name. An application -could also use CURLINFO_EFFECTIVE_URL to generate a file name from a -server-supplied redirect URL. Special care must be taken to sanitize such -names to avoid the possibility of a malicious server supplying one like -"/etc/passwd", "\\autoexec.bat", "prn:" or even ".bashrc". - -.IP "Server Certificates" -A secure application should never use the \fICURLOPT_SSL_VERIFYPEER(3)\fP -option to disable certificate validation. There are numerous attacks that are -enabled by apps that fail to properly validate server TLS/SSL certificates, -thus enabling a malicious server to spoof a legitimate one. HTTPS without -validated certificates is potentially as insecure as a plain HTTP connection. - -.IP "Showing What You Do" -On a related issue, be aware that even in situations like when you have -problems with libcurl and ask someone for help, everything you reveal in order -to get best possible help might also impose certain security related -risks. Host names, user names, paths, operating system specifics, etc. (not to -mention passwords of course) may in fact be used by intruders to gain -additional information of a potential target. - -Be sure to limit access to application logs if they could hold private or -security-related data. Besides the obvious candidates like user names and -passwords, things like URLs, cookies or even file names could also hold -sensitive data. - -To avoid this problem, you must of course use your common sense. Often, you -can just edit out the sensitive data or just search/replace your true -information with faked data. - +See \fIcurl_easy_getinfo(3)\fP. .SH "The multi Interface" The easy interface as described in detail in this document is a synchronous interface that transfers one file at a time and doesn't return until it is |