Is allowing unfiltered curl request from a website a vulnerability?

Question

Recently I was on a website which provided some non-sense feature:

• Enter a URL
• Press enter
• HTML source of a given URL is displayed

It basically fetched a URL and just dumped the contents of it. It could be XML, txt, HTML, any reachable path via curl.

Now it struck me that this should be quite dangerous, am I right?

I have no Linux at hand and I could not find this site but a quickly hacked PHP page on my Windows machine happily consumed the URL:

file://D:/something/index.html

and presented it to me. Wouldn't this basically allow an attacker to roam the machine the script is running on? Would this URL

file:///etc/passwd

work on linux?

Is there some other obvious issues with that?

Impersonating someone else accessing other resources via schemes like POP3, LDAP, smb?

While writing this I asked myself whether white-listing schemes to HTTP[S] and maybe FTP would fix those issues?

I still would be able to impersonate a visitor on a site via this page but I am not aware of any issues except visiting illegal content or probably bypass things like censoring.

Answer 1

If the input is not carefully filtered, then that is a vulnerability called Server Side Request Forgery (SSRF).

There is even a common weakness enumeration number and page for it. https://cwe.mitre.org/data/definitions/918.html

By providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the request, possibly bypassing access controls such as firewalls that prevent the attackers from accessing the URLs directly. The server can be used as a proxy to conduct port scanning of hosts in internal networks, use other URLs such as that can access documents on the system (using file://), or use other protocols such as gopher:// or tftp://, which may provide greater control over the contents of requests.

By exploiting this vulnerability an attacker can:

• Scan hosts from the server's internal network that is not normally accessible
• Enumerate and attack services that are running on these hosts
• Exploit trust relationships which the vulnerable server might have
• Proxy HTTP traffic through the vulnerable server which will mask the source of the traffic

Unfiltered cURL support is even worse than a normal SSRF vulnerability because cURL supports many URL schemas besides HTTP and HTTPS. Run #curl-config --protocols to see what is supported.

• You can access local files with the file:// URL scheme (curl file:///etc/passwd does work on linux)
• It’s possible to use the dict:// URL schema to make requests to any host on any port and send custom data. The URL dict://host:port/command will cause the server to connect to a host and send the string command to the specified port.
• Access different services:
  • ldap://
  • ftp://
  • scp://
  • smb://
  • telnet://
  • imap://
  • pop3://
  • smtp://
  • rtsp://
  • tftp://

Answer 2

Well depending on how they've implemented this feature it could indeed be quite dangerous. In addition to to the risks you've mentioned there's also the potential for non-public URLs to be retrieved by the system. For example retrieving http://127.0.0.1 would retrieve localhost.

This can be a risk as things like administration panels are commonly deployed over HTTP(s) these days, and are likely to be accessible to the local server and not random other IPs.

Now of course you may find that the site is correctly filtering all these attacks as is wouldn't be apparent unless you try them (which of course could be legally dubious depending on your jurisdiction..)