SECURITY / COMPATIBILITY Issue: Do not use file_get_contents() on URLs

Note for WP Cerber users: actually, there is no security issue. No worries, everything is OK. As usual.

Hi, Scott!

Thanks for diving into this topic! Let me set those things straight. Ability to load content from some URL via file_get_contents() is not a security issue. It’s just a way, one of the many other ways know for hackers. And this way is enabled by default, anyway. This is a normal way for retrieving URLs as well as using CURL. It can’t be more or less secure than cURL. Hosting providers sometimes disable retrieving URLs via file_get_contents() for false security reasons, just in case. Some security blogs may recommend using allow_url_fopen = 0 allow_url_include = 0 as a prevention from being used by hackers. I’m sorry, but there are a lot of ways to bypass that. Malware code can use cURL instead. Can’t it? Malware code can be invoked with a GET/POST parameter that contains malicious code. Again, disabling just one way doesn’t make a website more protected. To me, it is just like “security through obscurity”. What does really make a website less protected? Just for instance:

• Allowing execute PHP code in the uploads folder. I mean having this folder without php_flag engine off in the .htaccess file.
• Using buggy and vulnerable plugins like Gravity Forms. Many thousands of websites were infected with backdoors and destroyed via it.
• Enabling vulnerable REST API without any reason for it. Many thousands of websites were attacked via the known vulnerability.

None of them are related to file_get_contents() or fopen(). Right?

Let’s move on. I agree with you on HTTPS connection to Cerber Lab nodes. Any data in an HTTP connection can be spoofed. Using HTTPS prevents the plugin from being connected with fake Cerber Lab node. Currently, any user can select HTTPS or HTTP depends on their personal preferences and performance of its web server where their website is located on. For now, the plugin doesn’t use this channel to send or receive sensitive information at all. And, by the way, all data is going through carrier’s networks and data centers, not a public Wi-Fi or something like that. So, I leave this option for performance reason. HTTPS consumes a lot of resources for handshakes. In future releases, this option will be removed and all communications will go through HTTPS.

To sum up, in future releases I’ll replace file_get_contents() with more compatible cURL because it will make some users happier and yes there will not be an option to select HTTP.

P.S. If you want to get really protected website: https://wpcerber.com/turn-wordpress-into-fort-knox/

Note for WP Cerber users: actually, there is no security issue. No worries, everything is OK.

Actually that is not entirely true. He’s not saying there is a full-blown immediate vulnerability, but you’re not making your code as secure as it should be, and as it stands, it can be leveraged.

Ability to load content from some URL via file_get_contents() is not a security issue.

That’s actually not true either. I suggest you research this a bit further, because your reasons are incorrect. It’s not going to single-handedly secure a website by making this switch, but developers should be using the most secure methods possible.

Using file_get_contents() on URLs is not a good coding practice, and that’s fairly well known. It’s got too many flaws to list. All WordPress plugins should be using the WP HTTP API, because it is a more reliable and secure mechanism. Even replacing file_get_contents() with cURL is not the best practice…it really should be the WP HTTP API.

Dear Blackhawk, where are your arguments? In fact, some of those so-called best practices are just stereotypes. Replacing file_get_contents() with cURL doesn’t improve security, it’s just more compatible with some hosting environments.

When you are blaming file_get_contents() or cURL you are barking up the wrong tree. Bad and buggy code from uneducated coders is a real security issue.

@gioni,

Let me preface this by saying that we like your plugin a lot. We like you a lot. But we do disagree on this point.

It’s not just about cURL or WP HTTP API being more compatible, and it’s not just stereotypes. There are false security measures, but this isn’t one.

file_get_contents() can be leveraged in a number of ways. It was designed primarily for accessing files on the same server, whereas cURL and the WP HTTP API were designed specifically for remote retrieval, and much more robust configuration abilities. WP HTTP API goes far beyond cURL’s capabilities in that it provides a lot of safety checks and configuration options, and better allows a site owner to control and monitor requests made from the server to remote sources.

This is an essential part of a “defense in depth” security strategy, and would more specifically fall under the principle of least privilege, among others. It’s not necessary to leave many open routes to access URLs from other sites. Only one is needed, and it should be tightly limited.

Please don’t say we’re barking up the wrong tree though.

We know that you are aware of and understand the security risks associated with file_get_contents() because you check for these in your Plugin Inspector plugin.

In the latest version — V 1.5 — in the unsafe.php file, at the top of the file (lines 2-7), in the PHP comments, you have this description:

/*
 * Unsafe function in context of plugin/themes for safe websites
 * Generally, those functions are safe, but under certain circumstances those functions may be used to hack site or to lead to the disclosure of vital information
 *
 *
 */

To quote your own words, “Unsafe function in context of plugin/themes for safe websites. Generally, those functions are safe, but under certain circumstances those functions may be used to hack site or to lead to the disclosure of vital information.”

That’s a good summary of the issue.

You have file_get_contents() listed below this on line 23:

'file_get_contents' => array('Read entire file into a string. May be used to load malicious code from the external source/website without any restrictions.',2),

To quote your own description: “Read entire file into a string. May be used to load malicious code from the external source/website without any restrictions.”

cURL has the same issues, and you note this on line 24:

'curl_exec' => array('Load external data from any web server. May be used to load malicious code from the external source without any restrictions.',2),

You do list some WP HTTP API functions as well (which we would not necessarily agree with), but there is a key difference — you didn’t add the phrase “without any restrictions” to the the WP HTTP API functions. That’s one of the key differences with the WP HTTP API, is that site owners you can add restrictions (and even block all external requests if they want to go that far).

WordPress can’t monitor and add any restrictions to file_get_contents() or cURL functions when used outside of the WP HTTP API.

No one is trying to tell you what to do. All anyone can ask is that you research the issue in more depth, and reconsider. You’re the developer, and decisions are obviously up to you.

Cheerio.

• This reply was modified 7 years, 9 months ago by blackhawkcybersec.
• This reply was modified 7 years, 9 months ago by blackhawkcybersec.
• This reply was modified 7 years, 9 months ago by blackhawkcybersec.

Thanks for citing me! I appreciate your desire to make some security related stuff stronger and it’s normal to be concerned by security. But please read carefully all my messages cause I want to set things straight once again.

To me ““defense in depth” security strategy” is kind of paranoia in the particular context we have. We are unable (or don’t want) to get a more reliable solution, so let’s block everything we have on the web server. In other words, let’s block selling knives because some bad guys can use it for committing crimes. Meanwhile, you have a real security issue with the ability to execute PHP code in the uploads folder.

file_get_contents() is just a way, one of many other ways, there is no special, “right” purpose for this function like reading files from a local hard drive only. It’s a fallacy. It’s absolutely the same situation with cURL. Period.

All my warnings about file_get_contents() you have mentioned are just warning about a possibility. The warning tells that the function can be exploitable under some circumstances. The function can be insecure only with terrible code created by uneducated coders or intentionally used in the malicious code. In the vast majority cases coders make file_get_contents() vulnerable, not hackers. Check the usage of this function in my code and you will be sure that my code and usage of the function is safe as it must be. No more discussions about file_get_contents() or cURL.

If WordPress can monitor something that means hacker or bad coder can do that with hooks easily. No exception. That leaves a website unprotected. How is it possible? Easily. You think that you disable using WP HTTP API and everything is fine, but it is not because bad guys use cURL instead. Sorry, WP HTTP API will not be used, just cURL.

You should trust the security plugin that protects your website. If you don’t trust, don’t use it.

To me ““defense in depth” security strategy” is kind of paranoia in the particular context we have. We are unable (or don’t want) to get a more reliable solution, so let’s block everything we have on the web server.

I’m sorry, but that’s simply not accurate. We’re clearly not going to agree on this.

All my warnings about file_get_contents() you have mentioned are just warning about a possibility. The warning tells that the function can be exploitable under some circumstances.

Yes…that’s exactly the point though.

If WordPress can monitor something that means hacker or bad coder can do that with hooks easily. No exception. That leaves a website unprotected. How is it possible? Easily. You think that you disable using WP HTTP API and everything is fine, but it is not because bad guys use cURL instead. Sorry, WP HTTP API will not be used, just cURL.

That’s a bit of a ridiculous thing to say. Please become more familiar with it before saying things like this. It’s simply a library of code that’s part of the WP core code, that wraps around cURL and adds additional abilities.

I don’t think anyone is saying they don’t trust you…just asking you to make some improvements to the code.

You are just kidding me. If you dive into code for a sec, you see this:

$r = apply_filters( 'http_request_args', $r, $url );

Should I explain how can it be used?

Besides, I have a one million reasons not to use this API.

Nonsense! Sheer nonsense.

If you dive into code for a sec…

Yes, please do dive into the code. We know it inside and out. That hook allows filtering of the arguments used for an HTTP request.

By your logic, any application that uses programmatic hooks would be compromised and insecure. Following this logic, WordPress itself is not secure…so why even use it?

Again, nonsense.

If you have knowledge of an actual security issue in WordPress core code, then you should have reported it to the WordPress security team.

Besides, I have a one million reasons not to use this API.

You say this, but don’t list any. Do your research. You’d be hard pressed to find anyone else that agrees. On the other side there are many resources pointing out the issues with using file_get_contents() and cURL outside of the WP HTTP API.

Also, there are no issues with file_get_contents(), why do you red flag it in your Plugin Inspector plugin? By the arguments you’re using here, then you’re saying that your own Plugin Inspector plugin is a sham. Following logic, you can’t have it both ways.

Also, you already use certain functions from the WP HTTP API in your plugins, but you don’t use the WP HTTP API consistently. wp_remote_get() appears on lines 67 and 113 of wp-cerber/ripe.php. By your own logic, these would be security flaws, and you should remove these from your code. Whether you use our logic, or your logic, it would follow that there are security flaws in your code that need to be fixed. Again, following logic, you can’t have it both ways.

• This reply was modified 7 years, 9 months ago by blackhawkcybersec.

@gioni,

We don’t consider this issue resolved, so please don’t keep marking it as “Resolved”.

It would be one thing if you had even said that you would research the issue further, or look into it, but instead you’ve simply denied there is any issue.

Look, no one is here to criticize you personally…just to request improvements to insecure code. Insecure code can lead to severe consequences for users.

You’re free to ignore this. Just understand that users may decide not to use your plugin if you choose to ignore best practices.

– Scott

Finally, it happened. Now you guys showed your real goal. You are just smart attackers on some plugin you don’t like to see here on www.remarpro.com available and successful. Aren’t you?

I have neither obligation to answer you here or to implement your personal requests. You can use any arguments you want. They’re just your point of view. I explained my point of view and my approach. You ignored that. Fine. End of discussion.

@blackhawkcybersec, all ripe (WHOIS) requests are optional.

This discussion is closed to me. Period.

Finally, it happened. Now you guys showed your real goal. You are just smart attackers on some plugin you don’t like to see here on www.remarpro.com available and successful.

Wow, nothing could be further from the truth. Real goal? Attackers? Wow. We wouldn’t report the issue if we didn’t like your plugin…we just would not use it. We do use it ourselves. We just have had to make some modifications to the code to make it more secure.

Maybe don’t automatically assume someone is attacking you. Maybe listen to the concern, and look into it on your own? Maybe get third party feedback from others.

I’ve never said anything negative about you, and I appreciate the work you’ve put into this plugin.

Anyway, do what you like. Take care.