blackhawkcybersec

Hi Mike,

Thanks for clarification. That was a good move. We saw a lot of user issues for that same reason…the autofill.

It usually seems best for each dev team to focus on their specialty anyway…we specialize in anti-spam + security, and you guys specialize in great ecommerce software. We’ll keep your reg forms safe. ??

Hi @dmahler,

Before the last update WC had a really weak antispam mechanism on the form that was removed. Spammers could get around it easily though.

Spam (all types) can start/stop or increase/decrease at any time, regardless of this. It all depends on the spammers. It’s honestly surprising if you didn’t get spam before that.

You can install WP-SpamShield to take care of the registration spam (and all other spam). It’s powerful, accurate, and protects WC specifically.

– BH

@prathameshp From a security point of view, it might not be the best thing to recommend that people disable their security/anti-spam plugins. Both Jetpack and WP-SpamShield have a very large user base, so it might be worth spending some time fixing compatibility issues, instead of recommending people disable these. We have found some issues in your AJAX code that could cause conflicts with a lot of other plugins, because there is some deviation from WordPress coding best practices. We have a compatibility guide for plugin developers that may help. You can use the form at the bottom to contact us if you need help or have questions.

@jenniecreates7 It looks like you’re using both WP-SpamShield and Jetpack. IMO you should not have to disable those. We do have some info about the Email Subscribers & Newsletters plugin on our Known Issues and Plugin Conflicts page due to the issues mentioned above. We also provide some alternative solutions. If you have any questions or need further help, feel free to contact our tech support team.

– B

Hi Mike,

We would disagree about the alert being “over the top” or “alarmist”. 2016 was a record year for security breaches, and there was a 40% increase in security breaches from 2015 to 2016.

Most security breaches occur from not site owners overlooking the basics.

When a website owner experiences a hack from something like this that is easily preventable, they would not call a security alert like this “alarmist” if it would have helped prevent the hack.

When there is a known security issue, it’s important that it is addressed and patched, no matter how seemingly small. When it comes to security, it’s often the little things that get you.

The alert in the admin simply does these 4 things:

1. “Insecure WordPress version detected.” – Informs the admin that the current version of WordPress is not secure. (It has at least 1 known vulnerability.) This is 100% true…unless mitigation is applied, the site is vulnerable. (“Vulnerability” does not equal “Malware”, so don’t confuse that.)
2. “Your site is running WordPress version 4.7.4, which has 1 known security vulnerabilities.” – States how many known vulnerabilities there are for that version.
3. “You should upgrade WordPress as soon as possible.” – Lets the admin know that they should upgrade as soon as possible. Even though there is no upgrade available yet, this is still true…as soon as there is, they should upgrade as soon as it is possible. (If there is no upgrade available, then manual mitigation methods will be required.)
4. “More Information” – This provides a link to more information about the issue. The admin should read this to fully understand the issue and inform themselves of available options for mitigation.

It’s strictly informative and informational. On the whole, it seems relatively neutral and calm.

I’m not sure how any of that could be considered “alarmist”. If we have the ability to easily detect an issue that could affect user security, we feel the obligation to do so.

Don’t forget that we deal with clients day-in and day-out just like you do. We have a good deal of experience in this area. Our clients are getting the same alerts. It’s all about how you handle it. When clients have a question about something like this, we let them know what we’ve done to mitigate the threat and secure the site. We don’t recommend ignoring issues, or pretending they don’t exists — in fact the more proactive you can be, the better. When you find out about a threat, let them know as soon as possible and that you are mitigating the threat. Then when you have taken the proper steps to mitigate the threat, let them know, and they’ll be fine, and will have confidence that you’re handling things in the future.

If you think about it, we’re providing you an opportunity to look awesome to your clients. ??

– BHC

Since we haven’t received any further communication or support requests, we’re going to mark this as resolved. If you have any further support requests, please use the official support channel. Thank you.

– BH

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.

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.

@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.

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.

@andreaskviby

Sadly, yes, it would seem so. No updates in two years, no responses from developer in a very long time.

An alternative we use is Query Monitor. It works a bit differently, but can help you find what plugins may be slowing down your site. It gives you a way to easily see errors, slow DB calls, repeated DB calls, DB calls by plugin, and a lot more. Using that with WP_DEBUG is an excellent way to see what plugins may be slowing down your site. Actually, it’s a bit more of a scientific method, so in that respect it was always better than P3, since P3 never showed the real cause of the issue.

That’s not an issue with the plugin. The errors you had posted are due to your site configuration. Errors should be hidden, but logged. You need to modify your site’s configuration.

In your php.ini file, either change or add the following:

display_errors = Off

You should also set ‘log_errors’ to ‘On’, and ‘set error_log’ to a secure location outside of the web root (inaccessible to the web). Do a little research on these first. You should set ‘display_errors’ right away though.

For more info, see the official PHP docs on php.ini config directives, as well as the OWASP cheat sheet.

@dave-r,

I would echo what @pronl said. WordPress 3.5.1 has 28 known security vulnerabilities. 3.5.1 is a 4 year old release…That’s ancient in internet time. There is no point in running a security plugin on a site like that. It won’t help.

Let’s put it this way: The only way to keep your site from being hacked is to upgrade it. There is no site that cannot be upgraded. If you don’t want to upgrade it, I would recommend shutting it down. Otherwise it’s only a matter of time until it gets hacked.

Thank you. Confirmed..it is being detected as PHP 7 compatible now.

Thank you. Confirmed..it is being detected as PHP 7 compatible now.

We’ve seen the same exact error for plugins with blank index.php files. I’ll try to track them down to give you more specifics.