KNOWN_RISKS: known risks when running and using curl and libcurl

Closes #19631

docs/KNOWN_RISKS.md

@@ -0,0 +1,137 @@
+<!--
+Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
+
+SPDX-License-Identifier: curl
+-->
+
+# Known Risks
+
+This is an incomplete list of known risks when running and using curl and
+libcurl.
+
+## Insecure transfers
+
+When using curl to perform transfers with protocols that are insecure or the
+server identity is unverified, everything that is sent and received can be
+intercepted by eavesdroppers and the servers can easily be spoofed by
+impostors.
+
+## Untrusted input
+
+You should **never** run curl command lines or use curl config files provided
+to you from untrusted sources.
+
+curl can do a lot of things, and you should only ask it do things you want and
+deem correct.
+
+Even just accepting just the URL part without careful vetting might make curl
+do things you do not like. Like accessing internal hosts, like connecting to
+rogue servers that redirect to even weirder places, like using ports or
+protocols that play tricks on you.
+
+## Command line misuse
+
+The command line tool and its options should be used and be expected to work
+as documented. Relying on undocumented functions or side-effects is unreliable
+as they may cause problems or get changed behavior between releases.
+
+For several command line options you can confuse either curl or the involved
+server endpoint by using characters or byte sequences for the option that are
+not expected. For example line feeds and carriage returns.
+
+## API misuse
+
+Applications using the libcurl API in a way that is not documented to work or
+even documented to not work, is unsafe and might cause security problems. We
+only guarantee secure and proper functionality when the APIs are used as
+documented.
+
+## Local attackers already present
+
+When there is a local attacker present locally, curl cannot prevent such an
+adversary to use curl's full potential. Possibly in malicious ways.
+
+## Remote attackers already present
+
+When there is a remote attacker already present in the server, curl cannot
+protect its operations against mischief. For example, if an attacker manages
+to insert a symlink in your remote upload directory the upload may cause
+havoc. Maybe the attacker makes certain responses come back with unexpected
+content.
+
+## Debug & Experiments
+
+We encourage users to test curl experiments and use debug code, but only in
+controlled environments and setups - never in production.
+
+Using debug builds and experimental curl features in production is a security
+risk. Do not do that.
+
+The same applies to scripts and software which are not installed by default
+through the make install rule: they are not intended or made for production
+use.
+
+## URL inconsistencies
+
+URL parser inconsistencies between browsers and curl are expected and are not
+considered security vulnerabilities. The WHATWG URL Specification and RFC
+3986+ (the plus meaning that it is an extended version) [are not completely
+interoperable](https://github.com/bagder/docs/blob/master/URL-interop.md).
+
+You must never expect two independent URL parsers to treat every URL
+identically.
+
+## Visible command line arguments
+
+The curl command blanks the contents of a number of command line arguments to
+prevent them from appearing in process listings. It does not blank all
+arguments, even though some that are not blanked might contain sensitive data.
+
+ - not all systems allow the arguments to be blanked in the first place
+ - since curl blanks the argument itself they are readable for a short moment
+   no matter what
+ - virtually every argument can contain sensitive data, depending on use
+ - blanking all arguments would make it impractical for users to differentiate
+   curl command lines in process listings
+
+## HTTP headers in redirects
+
+It is powerful to provide a set of custom headers to curl. Beware that when
+asking curl to follow HTTP redirects, it also sends those headers to the new
+URL which might be a different server. That might do another redirect etc.
+
+curl makes some limited attempts to not leak credentials this way when set
+using the standard curl options, but when you pass on custom headers curl
+cannot know what headers or details in those headers are sensitive.
+
+## Verbose logs
+
+When asked to provide verbose output and trace logging, curl may output and
+show details that are private and sensitive. Like for example raw credentials
+or the password weakly disguised using base64 encoding.
+
+## Terminal output and escape sequences
+
+Content that is transferred from a server and gets displayed in a terminal by
+curl may contain escape sequences or use other tricks to fool the user. Escape
+sequences, moving cursor, changing color etc, is also frequently used for
+good. To reduce the risk of getting fooled, save files and browse them after
+download using a display method that minimizes risks.
+
+## Legacy dependencies
+
+Every curl build is made to use a range of third party libraries. Each third
+party library also needs to be safe and secure for the entire operation to be
+risk-free.
+
+Relying on legacy dependencies is a risk.
+
+## Weak algorithms
+
+curl supports several cryptographic algorithms that are considered weak, like
+DES and MD5. These algorithms are still in use because some protocols and
+transfer options require use of them. For example NTLM or legacy HTTP Digest
+authentication.
+
+curl users should consider switching to servers and options that use modern
+and secure algorithms.

docs/Makefile.am

@@ -108,6 +108,7 @@ EXTRA_DIST =                                    \
  INTERNALS.md                                   \
  IPFS.md                                        \
  KNOWN_BUGS                                     \
+ KNOWN_RISKS.md                                 \
  MAIL-ETIQUETTE.md                              \
  MANUAL.md                                      \
  options-in-versions                            \