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:


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


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.

  • I'd appreciate it if you inform them about the potential security risk!
    – mucaho
    Commented Aug 1, 2015 at 22:04
  • 3
    Note: /etc/passwd is meant to be public. Private data is in /etc/shadow.
    – user10008
    Commented Aug 1, 2015 at 23:52
  • @mucaho I will if I find the page. Of course I won't try to verify the exploits as RоryMcCune pointed out it may be subject to local laws.
    – Samuel
    Commented Aug 2, 2015 at 9:02
  • @user10008: It is not meant to be public to the whole world - only to interactive users of the system (e.g. terminal access by an employee running the service). Grabbing /etc/passwd can be used as a POC that a file access vulnerability exists. Commented Aug 3, 2015 at 8:12
  • Depending on how it passes parameters, you might be able to make the website load itself in an infinite loop... Self Denial of Service?
    – billc.cn
    Commented Aug 5, 2015 at 15:11

2 Answers 2


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://
  • Yes, curl is a powerful tool. We have to handle it carefully. Commented Apr 12, 2018 at 4:19

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 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..)

  • 3
    I've seen plenty of scenarios in small offices where doing this exact sort of scan on 192.168.x.1 where 0 < x < 255 will turn up the control panel for the gateway router/modem/whatever -- and very few of those have any settings other than the default user/passwords set. From there the network (and the firmware) belong to the attacker, and with most people thinking that NAT defines a security barrier (which is ridiculous, but the way most networks are configured, even in many datacenters!), its usually easy pickings from there.
    – zxq9
    Commented Aug 2, 2015 at 7:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .