9

I am currently using file_get_contents() to get the title of a webpage, given the URL. On wamp, this works perfectly fine. However, when I shifted this to my web server, I came across a problem which lead me to this answer. (Which is to set allow_url_fopen to 1).

Is there a major security risk in setting this on? If yes, are there any alternate ways to grab the title of a webpage from the URL itself?

(Also, unsure of tags for this so please feel free to add/remove if appropriate!)

Edit (1) : Further research lead me to this question, which pretty much says that it is a risk as well, and to disable it if the application does not need it. Unfortunately this does not tell me enough about the risk involved.

Edit (2) : Quick note, I will be using this function with user input (the URL), and not internally, which is why I want to ensure there is absolutely no security risk involved

Community
  • 1
  • 1
Sainath Krishnan
  • 2,089
  • 7
  • 28
  • 43
  • For your Edit 1: No answer here on SO can tell you about the risk involved within your application or code because only you can say what the risk actually is. For your Edit 2: You can never ensure that there is absolutely no security risk involved. However you can review your program and then ensure that values that are being worked with contain the information you expect there for sure. That should give you security that the application works as expected. – hakre Jun 06 '14 at 05:36

2 Answers2

11

This is just one reason why you may want allow_url_fopen set to 0

Let's say you allow users to enter a url, and you have your server fetch this url.

You might code something like this: - YOU SHOULD NOT CODE THIS -

echo file_get_contents($_POST['url']);

Problem is that there is a security issue here. Somebody could pass a file path instead of a url and have access to your server's files.

For example, somebody might pass /etc/passwd as a url, and be able to view its contents.

Now, if allow_url_fopen were set to 0, you wouldn't be using file_get_contents to fetch URL's, you would be using CURL.

Ryan
  • 14,392
  • 8
  • 62
  • 102
Maury
  • 610
  • 5
  • 7
  • Ah that example made it very clear, thank you! – Sainath Krishnan Jun 05 '14 at 00:44
  • You really ought to _emphasize_ that the code you have written should **not** be used. People tend to copy / paste. I've seen software with exploits on this level, and it is from incompetent developers. – Ryan Jun 05 '14 at 00:45
  • 2
    `Curl` does not face the same security threat that `file_get_contents` does? – Sainath Krishnan Jun 05 '14 at 00:47
  • Alright, added some emphasis to my post. And Curl does not have this issue. – Maury Jun 05 '14 at 00:51
  • The rule of thumb generally is if you're grabbing data from an external URL (with libcurl or any other method) it should be treated as untrusted input. Grabbing external data can be perfectly safe if you keep that in mind; it's all relative to how you are allowing the data to be used within your server environment. – l'L'l Jun 05 '14 at 00:55
  • @l'L'l I am getting the URL, running the function, and using regex to isolate the `` tags, and saving that to a database. I see the potential for SQL injection here, so want to make sure `curl` can handle it, if not I'll have to find a way to – Sainath Krishnan Jun 05 '14 at 02:51
  • -1: This answer is misleading. To distinct between `$_POST['url']` being an URI or a path to a file should be independent to I/O operation, but first of all by verifying the input string for being a valid HTTP/S URI. – hakre Jun 05 '14 at 22:11
  • @hakre - this code should not be used, whatsoever. I was simply giving an example of a vulnerability. – Maury Jun 05 '14 at 23:19
8

allow_url_fopen is fine. If you need the feature, enable it. There are better tools out there for loading data from remote URLs (like the curl extension), but it's good enough for some simple use cases.

Its close relative, allow_url_include, is not safe. It allows functions like include() and require() to load and run code from remote URLs, which is a really bad idea. Leave that one turned off.

In the past, allow_url_include didn't always exist as a distinct option, so it was necessary to turn allow_url_fopen off to prevent badly written scripts from including data from remote URLs. That's no longer the case, though.

Ryan
  • 14,392
  • 8
  • 62
  • 102
  • Please keep in mind that allow_url_include can be emulated with allow_url_fopen and the eval-keyword. Even though, I think it's nearly impossible to restrict a user to the local machine only. There are much ways to access the internet, like curl- and stream-functions. – The Wavelength Jun 05 '14 at 00:14
  • @TheWavelength: Sure. But `eval(file_get_contents($user_input))` is at least something you're much less likely to write by accident. :) –  Jun 05 '14 at 00:16
  • If you want to use curl as HTTP wrapper for file_get_contents, you need to endable that setting. See as well: http://www.php.net/manual/en/context.curl.php - Just FYI, as I see this getting unnoticed lately and the curl extension getting thought of of not shipping with wrappers at all. – hakre Jun 06 '14 at 05:38
  • 1
    I'd like to hear the reason why exactly `allow_url_fopen` is fine and if this whole issue change now in 2016? – AlexioVay Nov 21 '16 at 05:02
  • @Vaia Still fine. Nothing's really changed since I wrote this. –  Nov 21 '16 at 05:09
  • Is this relevant or applicable to my question I just asked? Since I can't think of other solutions: http://stackoverflow.com/questions/40712982/how-to-implement-my-own-cms-hosted-on-a-remote-domain-in-all-my-projects @duskwuff – AlexioVay Nov 21 '16 at 05:14