738
738
.IP "Proxy Auto-Config"
740
740
Netscape first came up with this. It is basically a web page (usually using a
741
\&.pac extension) with a javascript that when executed by the browser with the
741
\&.pac extension) with a Javascript that when executed by the browser with the
742
742
requested URL as input, returns information to the browser on how to connect
743
743
to the URL. The returned information might be "DIRECT" (which means no proxy
744
744
should be used), "PROXY host:port" (to tell the browser where the proxy for
745
745
this particular URL is) or "SOCKS host:port" (to direct the browser to a SOCKS
748
libcurl has no means to interpret or evaluate javascript and thus it doesn't
748
libcurl has no means to interpret or evaluate Javascript and thus it doesn't
749
749
support this. If you get yourself in a position where you face this nasty
750
750
invention, the following advice have been mentioned and used in the past:
752
- Depending on the javascript complexity, write up a script that translates it
752
- Depending on the Javascript complexity, write up a script that translates it
753
753
to another language and execute that.
755
- Read the javascript code and rewrite the same logic in another language.
755
- Read the Javascript code and rewrite the same logic in another language.
757
- Implement a javascript interpreted, people have successfully used the
758
Mozilla javascript engine in the past.
757
- Implement a Javascript interpreted, people have successfully used the
758
Mozilla Javascript engine in the past.
760
760
- Ask your admins to stop this, for a static proxy setup or similar.
1063
1063
.SH "Security Considerations"
1065
libcurl is in itself not insecure. If used the right way, you can use libcurl
1066
to transfer data pretty safely.
1065
The libcurl project takes security seriously. The library is written with
1066
caution and precautions are taken to mitigate many kinds of risks encountered
1067
while operating with potentially malicious servers on the Internet. It is a
1068
powerful library, however, which allows application writers to make trade offs
1069
between ease of writing and exposure to potential risky operations. If
1070
used the right way, you can use libcurl to transfer data pretty safely.
1068
There are of course many things to consider that may loosen up this
1072
Many applications are used in closed networks where users and servers
1073
can be trusted, but many others are used on arbitrary servers and are fed
1074
input from potentially untrusted users. Following is a discussion about
1075
some risks in the ways in which applications commonly use libcurl and
1076
potential mitigations of those risks. It is by no means comprehensive, but
1077
shows classes of attacks that robust applications should consider. The
1078
Common Weakness Enumeration project at http://cwe.mitre.org/ is a good
1079
reference for many of these and similar types of weaknesses of which
1080
application writers should be aware.
1071
1082
.IP "Command Lines"
1072
1083
If you use a command line tool (such as curl) that uses libcurl, and you give
1073
option to the tool on the command line those options can very likely get read
1084
options to the tool on the command line those options can very likely get read
1074
1085
by other users of your system when they use 'ps' or other tools to list
1075
1086
currently running processes.
1077
1088
To avoid this problem, never feed sensitive things to programs using command
1089
line options. Write them to a protected file and use the \-K option to
1081
1093
\&.netrc is a pretty handy file/feature that allows you to login quickly and
1091
1103
.IP "Clear Text Passwords"
1092
1104
Many of the protocols libcurl supports send name and password unencrypted as
1093
1105
clear text (HTTP Basic authentication, FTP, TELNET etc). It is very easy for
1094
anyone on your network or a network nearby yours, to just fire up a network
1106
anyone on your network or a network nearby yours to just fire up a network
1095
1107
analyzer tool and eavesdrop on your passwords. Don't let the fact that HTTP
1096
1108
Basic uses base64 encoded passwords fool you. They may not look readable at a
1097
1109
first glance, but they very easily "deciphered" by anyone within seconds.
1099
To avoid this problem, use HTTP athentication methods or other protocols that
1111
To avoid this problem, use HTTP authentication methods or other protocols that
1100
1112
don't let snoopers see your password: HTTP with Digest, NTLM or GSS
1101
authentication, HTTPS, FTPS, SCP, SFTP and FTP-kerberos are a few examples.
1113
authentication, HTTPS, FTPS, SCP, SFTP and FTP-Kerberos are a few examples.
1116
The CURLOPT_FOLLOWLOCATION option automatically follows HTTP redirects sent
1117
by a remote server. These redirects can refer to any kind of URL, not just
1118
HTTP. A redirect to a file: URL would cause the libcurl to read (or write)
1119
arbitrary files from the local filesystem. If the application returns
1120
the data back to the user (as would happen in some kinds of CGI scripts),
1121
an attacker could leverage this to read otherwise forbidden data (e.g.
1122
file://localhost/etc/passwd).
1124
If authentication credentials are stored in the ~/.netrc file, or Kerberos
1125
is in use, any other URL type (not just file:) that requires
1126
authentication is also at risk. A redirect such as
1127
ftp://some-internal-server/private-file would then return data even when
1128
the server is password protected.
1130
In the same way, if an unencrypted SSH private key has been configured for
1131
the user running the libcurl application, SCP: or SFTP: URLs could access
1132
password or private-key protected resources,
1133
e.g. sftp://user@some-internal-server/etc/passwd
1135
The CURLOPT_REDIR_PROTOCOLS and CURLOPT_NETRC options can be used to
1136
mitigate against this kind of attack.
1138
A redirect can also specify a location available only on the machine running
1139
libcurl, including servers hidden behind a firewall from the attacker.
1140
e.g. http://127.0.0.1/ or http://intranet/delete-stuff.cgi?delete=all or
1141
tftp://bootp-server/pc-config-data
1143
Apps can mitigate against this by disabling CURLOPT_FOLLOWLOCATION and
1144
handling redirects itself, sanitizing URLs as necessary. Alternately, an
1145
app could leave CURLOPT_FOLLOWLOCATION enabled but set CURLOPT_REDIR_PROTOCOLS
1146
and install a CURLOPT_OPENSOCKETFUNCTION callback function in which addresses
1147
are sanitized before use.
1149
.IP "Private Resources"
1150
A user who can control the DNS server of a domain being passed in within
1151
a URL can change the address of the host to a local, private address
1152
which the libcurl application will then use. e.g. The innocuous URL
1153
http://fuzzybunnies.example.com/ could actually resolve to the IP address
1154
of a server behind a firewall, such as 127.0.0.1 or 10.1.2.3
1155
Apps can mitigate against this by setting a CURLOPT_OPENSOCKETFUNCTION
1156
and checking the address before a connection.
1158
All the malicious scenarios regarding redirected URLs apply just as well
1159
to non-redirected URLs, if the user is allowed to specify an arbitrary URL
1160
that could point to a private resource. For example, a web app providing
1161
a translation service might happily translate file://localhost/etc/passwd
1162
and display the result. Apps can mitigate against this with the
1163
CURLOPT_PROTOCOLS option as well as by similar mitigation techniques for
1166
A malicious FTP server could in response to the PASV command return an
1167
IP address and port number for a server local to the app running libcurl
1168
but behind a firewall. Apps can mitigate against this by using the
1169
CURLOPT_FTP_SKIP_PASV_IP option or CURLOPT_FTPPORT.
1172
When uploading, a redirect can cause a local (or remote) file to be
1173
overwritten. Apps must not allow any unsanitized URL to be passed in
1174
for uploads. Also, CURLOPT_FOLLOWLOCATION should not be used on uploads.
1175
Instead, the app should handle redirects itself, sanitizing each URL first.
1178
Use of CURLOPT_UNRESTRICTED_AUTH could cause authentication information to
1179
be sent to an unknown second server. Apps can mitigate against this
1180
by disabling CURLOPT_FOLLOWLOCATION and handling redirects itself,
1181
sanitizing where necessary.
1183
Use of the CURLAUTH_ANY option to CURLOPT_HTTPAUTH could result in user
1184
name and password being sent in clear text to an HTTP server. Instead,
1185
use CURLAUTH_ANYSAFE which ensures that the password is encrypted over
1186
the network, or else fail the request.
1188
Use of the CURLUSESSL_TRY option to CURLOPT_USE_SSL could result in user
1189
name and password being sent in clear text to an FTP server. Instead,
1190
use CURLUSESSL_CONTROL to ensure that an encrypted connection is used or
1191
else fail the request.
1194
If cookies are enabled and cached, then a user could craft a URL which
1195
performs some malicious action to a site whose authentication is already
1196
stored in a cookie. e.g. http://mail.example.com/delete-stuff.cgi?delete=all
1197
Apps can mitigate against this by disabling cookies or clearing them
1200
.IP "Dangerous URLs"
1201
SCP URLs can contain raw commands within the scp: URL, which is a side effect
1202
of how the SCP protocol is designed. e.g.
1203
scp://user:pass@host/a;date >/tmp/test;
1204
Apps must not allow unsanitized SCP: URLs to be passed in for downloads.
1206
.IP "Denial of Service"
1207
A malicious server could cause libcurl to effectively hang by sending
1208
a trickle of data through, or even no data at all but just keeping the TCP
1209
connection open. This could result in a denial-of-service attack. The
1210
CURLOPT_TIMEOUT and/or CURLOPT_LOW_SPEED_LIMIT options can be used to
1211
mitigate against this.
1213
A malicious server could cause libcurl to effectively hang by starting to
1214
send data, then severing the connection without cleanly closing the
1215
TCP connection. The app could install a CURLOPT_SOCKOPTFUNCTION callback
1216
function and set the TCP SO_KEEPALIVE option to mitigate against this.
1217
Setting one of the timeout options would also work against this attack.
1219
A malicious server could cause libcurl to download an infinite amount of
1220
data, potentially causing all of memory or disk to be filled. Setting
1221
the CURLOPT_MAXFILESIZE_LARGE option is not sufficient to guard against this.
1222
Instead, the app should monitor the amount of data received within the
1223
write or progress callback and abort once the limit is reached.
1225
A malicious HTTP server could cause an infinite redirection loop, causing a
1226
denial-of-service. This can be mitigated by using the CURLOPT_MAXREDIRS
1229
.IP "Arbitrary Headers"
1230
User-supplied data must be sanitized when used in options like
1231
CURLOPT_USERAGENT, CURLOPT_HTTPHEADER, CURLOPT_POSTFIELDS and others that
1232
are used to generate structured data. Characters like embedded carriage
1233
returns or ampersands could allow the user to create additional headers or
1234
fields that could cause malicious transactions.
1236
.IP "Server Certificates"
1237
A secure application should never use the CURLOPT_SSL_VERIFYPEER option to
1238
disable certificate validation. There are numerous attacks that are enabled
1239
by apps that fail to properly validate server TLS/SSL certificates,
1240
thus enabling a malicious server to spoof a legitimate one. HTTPS without
1241
validated certificates is potentially as insecure as a plain HTTP connection.
1102
1243
.IP "Showing What You Do"
1103
1244
On a related issue, be aware that even in situations like when you have
1104
1245
problems with libcurl and ask someone for help, everything you reveal in order
added
removed
docs/libcurl/libcurl-tutorial.3
