Page MenuHomePhabricator

testwiki provides a vector to create production accounts (valid on all of CentralAuth) without a CAPTCHA
Closed, ResolvedPublic

Description

https://test.wikipedia.org/wiki/Special:UserLogin/signup does not ask for a CAPTCHA. test.wikipedia.org is fully connected to production CentralAuth. This provides a hole allowing you to create an account on any WMF site without a CAPTCHA.

I confirmed that once an account is created this way, you can log out, then do a fresh login into English Wikipedia with the credentials.

Event Timeline

Mattflaschen-WMF raised the priority of this task from to High.
Mattflaschen-WMF updated the task description. (Show Details)
Mattflaschen-WMF changed Security from None to Software security bug.
Restricted Application changed the visibility from "Public (No Login Required)" to "Custom Policy". · View Herald TranscriptJan 11 2015, 2:42 AM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript
csteipp added a subscriber: greg.

Are we ok accepting this risk? Or do we want to enable captchas on testwiki?

@greg, do you know if there's a QA issue that prevents us from using captchas there?

Are we ok accepting this risk? Or do we want to enable captchas on testwiki?

I don't like it, personally.

@greg, do you know if there's a QA issue that prevents us from using captchas there?

I'll defer to @dduvall and @zeljkofilipin.

If there are browser tests using production testwiki (I think most use Beta), they can use the CAPTCHA bypass password (see T91220: Pass MEDIAWIKI_CAPTCHA_BYPASS_PASSWORD in on Jenkins so GettingStarted browser tests pass). However, I think most browser tests don't need to create accounts.

It doesn't look like it was done for QA (change is rOMWC9b9992999908: Set $wgEnableCaptcha to false for test.wikipedia.org; it went through some back and forth after that)

I'll defer to @dduvall and @zeljkofilipin.

Note that neither of these two people have access to this ticket.

csteipp changed the edit policy from "Custom Policy" to "Custom Policy".
csteipp added a subscriber: mmodell.

I'll defer to @dduvall and @zeljkofilipin.

Note that neither of these two people have access to this ticket.

They do now. Also, @mmodell, another permission update fail.

However, I think most browser tests don't need to create accounts.

And if they needed to create accounts, they shouldn't be creating global wmf accounts.

@greg, do you know if there's a QA issue that prevents us from using captchas there?

I'll defer to @dduvall and @zeljkofilipin.

There's one test suite (PdfHandler's) that runs against a test wiki (test2) and it doesn't even perform authentication. So, no, enabling CAPTCHA on test and test2 shouldn't interfere with testing.

There's one test suite (PdfHandler's) that runs against a test wiki (test2) and it doesn't even perform authentication. So, no, enabling CAPTCHA on test and test2 shouldn't interfere with testing.

#TLDR

+1

#Details

All browser test jobs: https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/

Searching for wikipedia.org at the page finds two jobs:

https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-PdfHandler-test2.wikipedia.org-linux-firefox-sauce/
https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-ZeroBanner-en.m.wikipedia.org-linux-phantomjs/

As @dduvall said, PdfHandler does not even log in.
ZeroBanner is broken (and should be deleted), and probably running at en.m.wikipedia.org because no other environments were available at the time it was created.

csteipp changed the visibility from "Custom Policy" to "Public (No Login Required)".Sep 21 2015, 11:13 PM
csteipp changed the edit policy from "Custom Policy" to "All Users".
csteipp changed Security from Software security bug to None.