[wp-trac] [WordPress Trac] #13827: Spam Security Vulnerabilities in wp-signup.php w/MultiSite
WordPress Trac
wp-trac at lists.automattic.com
Thu Jun 10 17:40:17 UTC 2010
#13827: Spam Security Vulnerabilities in wp-signup.php w/MultiSite
--------------------------+-------------------------------------------------
Reporter: uglyrobot | Owner:
Type: defect (bug) | Status: new
Priority: high | Milestone: 3.0
Component: Multisite | Version: 3.0
Severity: critical | Keywords: needs-patch
--------------------------+-------------------------------------------------
I feel comfortable posting this here as the exploit is being observed in
the wild already. We have a signup code plugin, i’ve seen about 3 users
report spammers getting past the signup code without knowing it. I've also
seen similar ineffectiveness with captchas and other antisplog plugins out
there. Finally someone posted their logs
(http://premium.wpmudev.org/forums/topic/spammer-bypassed-signup-code) so
I could find the issue, and I think it could be classified as a security
bug in MultiSite.
The problem here is in the way the wp-signup.php handles stages. A plugin
can either choose to add a check to the user part or blog part of signups.
If you click the gimme a blog option it simply prints user info you
entered in the screen before as hidden inputs, it's not saved in the db or
anything until the blog form is completed:
{{{
<input type="hidden" name="stage" value="validate-blog-signup" />
<input type="hidden" name="user_name" value="test1011" />
<input type="hidden" name="user_email" value="test at uglyrobot.com" />
}}}
So a bot can simply post those hidden variables and skip the user part of
wp-signup.php completely, along with any protections a plugin has added to
it. There are nonces that are supposed to help with that, but from the
logs I think the bot is scraping it off the user page first, and since
they never submit that part of the form the nonce is still valid on the
blog part of the form as they are the same nonce id. Even if the nonce ids
were changed though a bot could first submit invalid data to the blog part
and collect the nonce there as well.
This bug essentially breaks half of the anti-spam plugins out there as
they add protection to the user part of the form, and bots can skip that
completely! As it stands a plugin can only protect user or blog signups,
not both without being annoying (2 captchas to signup, etc).
The only solution I can see is a complete rewrite of wp-signup.php,
probably to put user and blog fields on the same page maybe hidden with JS
as BuddyPress does. Unfortunately that means likely needed rewrites to
many signup protection plugins.
While we're considering a rewrite of wp-signup.php, I would like to see it
switched to a format more like BuddyPress uses, with it being a fake page
slug that can be defined in wp-config.php and calls the default theme page
template for display. Though that's more of a feature request for a future
release.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/13827>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list