WordPress MU

I've turned off blog registration completely. But magically spammers are still able to create them. The wp-signup.php file is horribly messy, so does anyone else have this problem and/or a solution?

not a wpmu issue. just delete it then change your admin password.

I'll agree with Demonicume on that one. Not an MU issue.

@lunabyte

So if it happens why isn't it a MU issue than ?

If it wasn't an MU issue it would not happen at all if you ask me.

Gee, let's see here.

Maybe because there are LOTS of things that could be the problem, and be causing the end result.

IF it were MU, and not another outside influence, do you realize how many threads and posts there would be about this in these forums?

Yep, not MU.

Can be, but the story does not tell if it's a fancy install, so I'm going out from a normal installation.

In that case it should not happen if you ask me, if it happens... it's not OK.

BTW, I have seen here very good IT people using WP and also people that were able to use it by reading the docs.

So you could imagine that an IT-person looks a little bit further by default, so might have solved the problem by himself.

BTW, you are not even telling what your ideas are what it could be, those "LOTS" of stuff, so that is not extra info for the TS at all.

Let's hope that the TS tells us more about his install.

How dare you. Of course it's an MU issue. I submitted a bug report with ample information to prove it:

http://trac.mu.wordpress.org/ticket/543

Check the POST variables.

I'll keep checking to see if it could possibly be any of the plugins, just in case and close the bug if I find that to still be the case without plugins.

So if you let people post to your form from an outside source, that's MU's fault?

So, that's how I dare.

I will humbly accept defeat: after removing the only 3 plugins that had anything to do with sign-ups, I received some more emails with POST attempts, and they do not in fact have blogs created. Strangely, they don't even have users created.

HOWEVER, I do not understand what you mean by "let people POST to MU from an outside source." Nothing prevents me from sending POST variables to any of your pages on any of your sites, unless you're constantly checking the REFERER... which MU doesn't do (and I could fake anyway).

So what's to be done to block people from POSTing to wp-signup.php?

Let's see... If someone (aka, the spammer bastards) post directly to your site, without actually being on your site, what could you do to prevent that?

Lots of things can be done for that.

First, it's only necessary where it's a problem. Like with comments, sign-ups, etc. Doing it on every page load doesn't make sense.

There are lots of ways to prevent sign-ups being posted directly, and checking http_referer isn't necessarily one of them as it can easily be spoofed or blocked by privacy software.

Then please tell me what will prevent some people from sending POST variables to my pages, and allow others.

Unless you're talking about things like captchas--meaning you want me to make them authenticate themselves somehow. Yeah, actually it was the captcha-like plugins that was screwing up the code, so go figure. I am sorry I thought it was the most wonderfully programmed MU wrapper and not the horribly programmed plugins that were the culprits.

But captchas are NOT a way to prevent people from POSTing from "outside" the site. HTML is asynchronous, there is no "outside" and "inside" the site. So I'm serious about learning about something I might not know... if you can give an example... the only thing I can think of is setting a cookie, but that doesn't sound like a very good idea to me. (And I'm not sure it would help if they just decided to hit the site once to grab the cookie anyway.)

In any case, thanks for looking at my thread and responding. I do owe you guys for bringing up the idea that it was a plugin.

A good captcha should work by providing validation to the input not by preventing the input (but I don't like capcha). A much easier thing to do is to change the name of the signup file, or change the names of the input fields.

Nope, I'm not referring to a captcha or a cookie. However, you're starting to think outside the box a bit.

However, a captcha would be one way to prevent someone from posting from an outside source as they would have to load the original page to get the captcha code which is expected on the second page. If that code is improperly posted then it (should) return to the main page with an error, thus rendering the posted data ineffective.

There are several ways to thwart remotely posted data. Overall, you need to know that the data being posted to the site came from someone who had already been there. As I mentioned previously, the sole use of http_referer isn't accurate as it can be spoofed or blocked from being sent.

Cookies would work, but is a little messier than some other types of user tracking. However, if set with a short duration for expiration, and only used with the signup procedure for example, it might not be that bad since it would disappear relatively quickly.

You can't really just set a single "security question", because if it doesn't change, then they can figure it out and just start posting the "answer" with their other data.

In the end however, all you can really do is try to plug as many holes in the dyke as possible. If someone wants to actually sit down, register, activate, and then post a spam blog, they're going to get though.

However, since it's a big numbers game, the vast majority of spammers won't do that. Let's say that a registration process from sign-up through activation and logging in to post takes 5 minutes.

If they automate that process, then they can do hundreds in an hour. If they actually have to sit down and type everything in, etc, is slows their numbers per hour way down, thus making it more of a waste of their time. They tend to just move onto the next easy target.

So, if you can discourage as many spam-friendly holes as possible, it cuts down splogs significantly. But what about the ones that do get through? Once their into the system, it's all "damage control".

Recently, disabling XMLRPC posting was added into the core. Unfortunately, it was taken back out in favor of Donncha making it into a plugin (where's it at, D? :D), but it initially disables a blog from allowing posts to be added through logging in through XMLRPC (like with a desktop type blogging client, or similar). It could then be turned on for users who would like it, etc.

This particular idea cuts splogs as well, as they tend to not actually visit the backend, but just post once through xmlrpc and move on. Again, being automated, they get more done in a short amount of time.

Other ways to control the "damage" exist, and I'm sure you could think of some. I've got several in place on sites that I run or work with, all of which aim to either discourage registrations, or at the very least control the "damage" if they do sign up.

Another sign up option, if you haven't considered it, could (possibly, depending on your site) be to simply disallow a sign up from a certain location.

For example, if you run a site for people living in France, you could block sign-ups from outside of France. Granted that particular solution is far from being globally friendly, but in some cases it can work. I guess the downside of something like that is if you live in a country where a lot of splogs are coming from, but hey, nothing is perfect.

Anyway, there are really tons of things you can do. Specifically what actions you take would be up to you and your situation, as they can vary greatly from user to user.

Wow, thanks for the long post with suggestions. They're all good ideas.

However, this does not excuse MU from its behavior (which I have just again verified, even without the plugins, so the ticket is reopened with additional info).

This is an MU bug. MU should NOT allow a blog to be created if blog creation is turned off. Even if it's a non-spammer human trying to create a blog.

It's not a bug if a plugin was/is changing MU's behavior (although that's debatable). But I still see it happening, just with two POSTs instead of one.

So if it's not plugin code, again I say "how dare you!"

(i.e. How dare you imply that I should have to obfuscate my site in order to get an MU function to work.)

I'm really not trying to be a pain, and I'm sorry I posted this in Installation by mistake. Anyway, I have updated the ticket so you can ignore this if you want.

By the way, it's almost obvious enough to me why this is happening to create a patch, but I'm not really familiar with the wpmu functions enough to tell. Here is the section of code that seems to be deciding (notice how turning off BOTH works):

{{{
if( $active_signup == "none" ) {
_e( "Registration has been disabled." );
} else {
switch ($_POST['stage']) {
case 'validate-user-signup' :
if( $active_signup == 'all' || $_POST[ 'signup_for' ] == 'blog' && $active_signup == 'blog' || $_POST[ 'signup_for' ] == 'user' && $active_signup == 'user' )
validate_user_signup();
else
_e( "User registration has been disabled." );
break;
case 'validate-blog-signup':
if( $active_signup == 'all' || $active_signup == 'blog' )
validate_blog_signup();
else
_e( "Blog registration has been disabled." );
break;
case 'gimmeanotherblog':
validate_another_blog_signup();
break;
default :
$user_email = $_POST[ 'user_email' ];
do_action( "preprocess_signup_form" ); // populate the form from invites, elsewhere?
if ( is_user_logged_in() && ( $active_signup == 'all' || $active_signup == 'blog' ) ) {
signup_another_blog($newblogname);
} elseif( is_user_logged_in() == false && ( $active_signup == 'all' || $active_signup == 'user' ) ) {
signup_user( $newblogname, $user_email );
} elseif( is_user_logged_in() == false && ( $active_signup == 'blog' ) ) {
_e( "I'm sorry. We're not accepting new registrations at this time." );
} else {
_e( "You're logged in already. No need to register again!" );
}

if ($newblogname) {
if( constant( "VHOST" ) == 'no' )
$newblog = 'http://' . $current_site->domain . $current_site->path . $newblogname . '/';
else
$newblog = 'http://' . $newblogname . '.' . $current_site->domain . $current_site->path;
printf(__("<p>The blog you were looking for, %s doesn't exist but you can create it now!</p>"), $newblog );
}
break;
}
}

}}}

I wouldn't necessarily say it's obfuscation, that would be more like hiding/renaming wp-signup to something else (which can help too).

However, saying that you shouldn't have to is kind of like saying you shouldn't have to run a dozen other programs like anti-virus, a firewall, spyware protection, etc. just to run windows either. At least, that's how I see it. Then again, using that analogy, I guess I wouldn't be running MU either since I refuse to run windows. :D

Sure, sure, I won't disagree that the ideal WPMU installation allows people to sign up for blogs, and uses a variety of techniques to thwart spammers.

How can I complain too much? I mean WP and the MU wrapper were written for me for free. Your time to bother looking at my issue was kindly for free as well... if I do happen to have time, I will keep investigating the ticket (which I assigned to myself), and I will create a patch if possible.

Or maybe in the end, I'll find another reason why I was wrong about this being a bug. (The code looks fine actually.)

But either way, I appreciate the feedback and good humor ;)

Just to chime in here... I have a couple installs running with signups turned off. They've never, in fact, been turned on. Not a splog being created on either one, and one of them is crawled quite heavily.

I'm also thinking if there was a definative way to figure this out, some of us here would be zillionaires, as Blogger (for instance) still hasn't figure dout how to stop splogs, and they have google behind them. Sploggers use the same enough methods to create new blogs on any platform as they do to submit spams.

(also, I am glad to see that the thread did not degrade into name-calling.)

Do you have signups completely off, or just the blogs (like in my case)? When both users and blogs are turned off, I haven't seen anyone able to sign up.

I've collected a lot of splog attempts and I've noticed that MOST spammers do not know how to get through, they submit one of the POST variables incorrectly. However, there seems to be at least one spammer who sends the correct variables and is able to sign up.

Oops, nevermind, donncha replied to my ticket that this was fixed in the latest code (in SVN)! Thanks guys.

Signups were completely off in my case. I've also been collecting splog attemps on another install.