These are often used on crawlers, bots - not necessarily of the harmful variety - and other automated retrieval, transfer and storage scripts. They're very useful, but highly specialised for those particular tasks and often not needed on traditional web applications. Of course, these are often abused for retrieving malware payloads as well so enable at your own risk.

... Because nothing communicates over HTTP except for crawlers, bots and malware droppers...

I'm super confused as to how I'm supposed to communicate with an external API in PHP without `curl_exec`. Anything that requires even remotely complex header setups means you need curl?

If the API uses HTTP, it's fairly straightforward. PHP has had streams available for quite some time : https://php.net/manual/en/stream.contexts.php

Many shared hosts often don't have cURL and so stream_create_context is an alternative https://php.net/manual/en/function.stream-context-create.php

There's even a REST helper from 2006/2010 : http://www.wezfurlong.org/blog/2006/nov/http-post-from-php-w...

So apparently the streams API is deep magic that malware will never use? If you're going to pass around "cargo cult crap" (thanks McGlockenshire), at least make sure you're locking down _every_ equivalent of "dangerous function" that only malware and "badly written software" supposedly would use. To add a few to the holes others have listed, you should disable proc_open, popen, pcntl_exec. How about dl(), to close a (rare) vector for loading native code?

While we're doing drop-in magic stuff to mitigate problems, don't forget to put libxml_disable_entity_loader(true); at the beginning of every script.[0]

Why not disable file_put_contents? I always thought that was kind of a shoddy practice, and likely to appear in malware, too!

Why not set allow_url_include = off ? Surely this is in "badly written software" territory that is exploited by malware?

Obviously this isn't exhaustive, either. My point is that you can't wave a few boilerplate configurations over any PHP application to make it secure. That may be a sizable flaw in the platform, but if so, say that rather than trying to give people copy-paste "protection."

[0] https://www.idontplaydarts.com/2011/02/scanning-the-internal...

Which is why I suggested Suhoshin above: https://news.ycombinator.com/item?id=8056907 And on a number of replies advocated for certain precautions in addition to the much maligned disable_functions list.

I'm not going to visit this thread any longer as it's getting to be an exhausting exercise of having to wade through snark and general malaise. I'm reminded, once again, why I waited so long before making a single post on this forum.

You might want to look into lightening up a little. You gave objectively bad advice, backed by objectively bad reasoning, and were educated about your mistakes for free. There was a bit of snark, but not a single drop of general malaise, and most of what was said to you was very helpful considering your professed aims.

You found yourself in "Wovon man nicht sprechen kann, darüber muß man schweigen" territory on this topic, but don't be disheartened. Proper security is notably difficult.

Which specifically of my points will be addressed by adding Suhosin?

You gave some good advice. Assuming your software still works without cURL and with Suhosin, yes, you are probably going to avoid some attacks by using your disable_functions list and Suhosin. Still, I think what I and several others take issue with, is giving an example php.ini that was so incomplete and inconsistent with its reasoning.

To be fair, I've noticed allow_url_include is off by default.

I mean, I just use Guzzle to be honest, but my point is that Curl is super useful in day-to-day usage and handles certain things far better than the streams API. I mean heck, the streams API using SSL context defaults to not verifying the damned certificate! Curl on the other hand, won't even connect until you tell it what to explicitly trust.

Granted, IIRC they are fixing that SSL issue in 5.6, but there are a number of other things, and frankly you haven't given a good enough reason to get rid of `curl_exec`. Others, like system calls I can completely agree with! But frankly, if PHP can make a call out to the web somehow, which you need it to if you're using APIs, then there will always be a vector for getting external exploits on to the server provided you've got remote execution already.

Streams used to be the less secure option and CURL was recommended instead because it meant fopen() calls couldn't be hijacked for remote include vulnerabilities and the programmer had to at least mean to include a remote file.

I have to admit I've continued to avoid streams much of the time for this reason - even though they are useful.

Now with a second reply it's going to seem like I'm attacking you, but: Doesn't your method require allow_url_fopen? I hope I'm not jumping to conclusions here, but saying allow_url_fopen is required and virtuous, and cURL is evil, is absolutely crazy IMO. Please correct me if allow_url_fopen is not needed for your method.