tigertech

what i want to know is what the hell is the point of a login attack with no login name?

You’re assuming hackers are competent. In my experience, a good percentage of their scripts are horribly broken. (All software starts off broken; it just gets fixed in testing. But hackers have poor testing processes.)

The hacker is probably sitting in his basement thinking “My script has sent 10,000 different username and password combinations already; it’s going to guess the right one any moment now….”

>Part of the problem with error messages is that’s how many hackers get information in the first place…error messages give away far too much info.

[ Unhelpful comments moderated ]

You still just have this in there:

die('ERROR: 403 Forbidden');

You’re wasting the valuable support resources of other people by hiding the fact that you’re the one blocking legitimate requests. I’m tired of getting “I think there’s a problem with your servers” complaints from our customers who install this kind of plugin.

Again: Can you please at least tell your users that your plugin is the thing blocking requests to their sites, instead of hiding it behind a generic message?

Scott Allen wrote:

> It’s not so much that blocking query strings with “http” is wrong

I think you’ll find it’s wrong. Quite a few legitimate requests contain a URL in the query string, and it’s a perfectly reasonable thing to do, if uncommon. (Heck, the WordPress code itself contains one example!) I found several other legitimate cases you’ll block with a few seconds of grepping our customer logs.

As a suggestion from someone who has been dealing with security for thousands of WordPress sites for many years (both at the PHP level and the Apache server mod_security level), you should consider what a nightmare trying to block requests things by heuristics will be. You won’t get it right. Nobody does. You’ll have an unending stream of low-level complaints from annoyed people who eventually figure out that your plugin is blocking something that used to work just fine.

>A lot of SQL Injection attacks use this

That doesn’t matter since legitimate requests use this, too. You’ll find the same is true of many other things that look like low-hanging fruit, unfortunately.

But anyway: if you continue trying to do this, as I said, PLEASE make sure the error message mentions your plugin name so people know what to disable to fix false positives. Thanks!

Thanks.

You should release a new version now; this bug completely kills people’s WordPress sites when the number of scheduled tasks builds up to high numbers. The constant database rewrites of the wp_options “cron” value was causing several GB of database writes per hour on a site we saw.

These icons are “dashicons”, which use a custom font to display.

The problem you’re seeing happens if you’ve set your Web browser to use only certain fonts from your own computer, ignoring custom fonts sent by the Web server.

For example, this happens if you uncheck the “Allow users to choose their own fonts, instead of my selections above” box in the Firefox Preferences > Content > Fonts & Colors > Advanced section.

So you should check your browser’s font settings.

drezac: This thread was about a particular problem where WP Super Cache could cause “wp-cron.php” script to run multiple times per second due to a specific bug. That bug is fixed.

The wp-cron.php script also runs at other times, though, completely unrelated to WP Super Cache. It’s used for all sorts of things by all sorts of plugins. Unless your specific problem is that “wp-cron.php” runs many times per second, your issue (that wp-cron.php causes your site to become unresponsive) is not related to this thread, and may not be related to WP Super Cache at all.

As mbrsolution said, your best bet is to start a new thread. (But what people are going to tell you is to try disabling all your plugins, one by one, until the problem goes away, to find which plugin is the problem.)

As an observation, omitting the site URL in the description increases security somewhat if the phone is lost.

To login to a WordPress site that has this plugin enabled, an attacker needs to know three things:

1. What site it is;
2. The password;
3. The two-factor code.

If the site URL is included in the description, someone finding a lost phone knows two of these things; if it’s not, they only know one.

(That said, this observation is mostly just pedantic. In practice, the chance that a random person finding a lost phone would want to hack your WordPress site is pretty small. And hopefully people using this plugin have also chosen a strong password and protect their phone apps with a password, too.)

Thanks! The work you put into WP Super Cache is much appreciated, as always.

This issue didn’t get a response from the WP Super Cache author donncha here, so I created a ticket for it on the plugins Trac (which I wasn’t previously aware of and seems like the right place for such reports).

photocurio wrote:

Hmm.. maybe my problems have something to do with my usual hosting company: tiger tech.

I’m with tigertech.net, and this is the first we’ve heard of this problem. I know we have many customers using the WordPress 3.3 media uploader without complaints, so this does seem more like it’s related to something else like plugin problems, etc.

In a different thread you mentioned that it was happening with multiple hosting companies: Has something changed that makes you now think it might be related to just us? We’ll be glad to investigate; please contact our support folks.

Fabauthor, I’m with tigertech.net hosting.

I think there’s a misunderstanding here. Our one-click installer installs a “self-hosted” blog that’s unrelated to wordpress.com or www.remarpro.com. To login to that blog, you’d normally just visit your own blog page and look for the link to login there.

If this doesn’t help, please contact our friendly support folks by opening a ticket, sending us an e-mail or calling our toll-free support; our contact page has the details.

Thanks!

Takayuki Miyoshi,

Thanks for posting. Out of interest, how did you tell that that person was the true author? Just looking through Trac changes, etc.?

One of the things that’s surprising is that the malicious plugin author made it look like you uploaded it — it even shows up on your profile page. But it shows up on the other profile page you mentioned, too.

The plugin directory system really ought to prevent someone from being able to upload a plugin and make the page say that the author is a different registered user….

Beer — thanks for the kind words; yes, I’m one of the “techs” in Tiger Tech!

How can one know he/she has found the right one (BEFORE SIGNING UP!)?

I’d search Google and Twitter for any hosting company’s name. Ignore paid ads and referral links on the positive side, and crackpots on the negative side. What’s left? Nobody’s perfect, but they should have enough positive comments to indicate they’ve been around a while, and few enough negative comments that they don’t obviously suck.

I just tried this on several hosting company names, and the result closely matches what I’d expect based on years of experience dealing with those other companies (both positive and negative).