Executing file get contents() with remote URL parameter

Any security issues with this?

[lammert]

I have some algorithms and services in PHP I would like to make available for other websites. The plan is to provide the algorithms for free when the parameters supplied are small or the number of parameters are limited, and go to a subscription system for a full version.

Because the algorithms are proprietary in nature and some of the services use a large set of data in my MySQL database, I don't want to just hand over the PHP scripts to interested webmasters, but instead only the URLs to the scripts on my server. The idea is that the remote webmaster uses the file_get_contents() function with the URL of my PHP script as the parameter. Something like

$result = file_get_contents( "ht*p//example.com/my-script?var1=1&var2=2" );

I know there are security problems when including PHP scripts from a remote location and that is why remote including is switched off by default. Hackers can exploit the ability to run remote scripts by executing their code on a remote server from your PHP instance. But as far as I have researched, using the include technique with file_get_contents() only gives a string which can be processed further by the calling PHP instance. My remote scripts should have no interference with variables declared in the calling script and have no execute privilliges on the calling server because both the calling and serving PHP scripts are executed in different instances of PHP.

Is this a safe way of providing my services to others, or are there better ways to do this?

[PHP_Chimp]

Seeing as you are hosting this there is not much of a security issue for you (not much more than serving any page request). As you will just be serving a normal get request for that page.

The security issue is for the people using your script. As they have no control, so you could do what you wanted. However there are plenty of people that offer services like you are talking about, so they must be used.

[lammert]

Yes, I already figured out that for my side the security issues are equivalent to normal PHP based webpage processing. So I have to do the standard screening and encoding of the incoming parameters. Some potential users might however be affraid that I embed malicious PHP code in the result (which is not my plan :)) that could compromize their server, but as far as I understand the process there is only data transferred to a variable in their PHP script and they can do all the checking/filtering they want to.

[coopster]

Using

file_get_contents

to read the entire file into a string from a URL is not in and of itself dangerous. First, as you noted, delivering the appropriate document from your site is not an issue. That is done via browsers everyday. There is no difference between a user typing

http://www.example.com/my-script?var1=1&var2=2

into the browser and somebody else using

file_get_contents

to get the intended resource. You are going to deliver the same either way. You cover your own behind by scrubbing any GET request data before you process, format and respond.

The receiving site is only in as much danger as they will allow too. And quite honestly, if you are a trusted business partner they are going to want or need to request the information and display it! That may be in an <iframe> or it may be read in using

file_get_contents

, curl, ... whatever. The issue comes in when you have a look at PHP security and the level of lockdown that is occurring across the board. More and more shared hosting providers are turning off

allow_url_fopen

by default as that is what is being recommended to them. Therefore, anybody trying to retrieve data via

file_get_contents

from an external URL is going to get errors or broken code, including well-written code which relies upon this feature.

allow_url_fopen

is of changeable type

PHP_INI_SYSTEM

so the entry could be set in

php.ini

or

httpd.conf

-- but good luck with that on a shared host.

I figure it is your job to offer the data in as many formats as you think you could/should (http/html, xml, txt, etc) and how your end user decides to access and display it is their choice, their issue. If they are on shared hosting and are not allowed to retrieve it via the method they desire and their host is unwilling to override this setting for a particular domain/file on their end then they have to make some decisions about their hosting provider I guess.