[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