Page MenuHomePhabricator

Page titles on private wikis are exposed with index.php?curid=...
Closed, ResolvedPublic


Patch to hide page title on private wikis when curid parameter is passed

On private MediaWiki installations, page title are exposed to the user (e.g. in the URL in the tab) when curid parameter is passed to index.php. It allows people to make a list of pages in wiki by making bacth requests.

Version: unspecified
Severity: major

attachment hide-pagetitle-on-curid.patch ignored as obsolete


TitleReferenceAuthorSource BranchDest Branch
Draft: definitions: Drop Z7138, Z7139, Z7140repos/abstract-wiki/wikifunctions/function-schemata!29jforresterdrop-experimentalsmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:06 AM
bzimport set Reference to bz32276.
bzimport added a subscriber: Unknown Object (MLST).

oldid appears to allow a similar data-exposure attack; you'd have to iterate through more things but you could get a basic list of page titles along with the page & revision id numbers.

Created attachment 9399
unconditionally show a badtitle and fix returnto links pointing to badtitle

patch made with iAlex on IRC

attachment stop_exposing_title.patch ignored as private

Looks straightforward enough. Pinging Sam to see if we can get this into 1.18.

I am not sure what is the release process for security bugs :-(

At the very minimal it needs to be reviewed and deployed live first. Might need a backport in 1.17 too and immediate release of 1.17.X.

Created attachment 9417
stop exposing title and bump MW to version 1.17.1

patch against REL1_17:

  • does not update the returnto links
  • bump wgVersion to 1.17.1
  • update RELEASE-NOTES

attachment stop_exposing_title_REL1_17.patch ignored as obsolete

The RELEASE-NOTES entry is in the wrong section, it should be in "Changes since 1.17.0".

Tim is working on a security release now around this bug. We'll probably hold 1.18.0 final for this fix.

I applied the patch to trunk, and found that there were still two instances of the actual title in the page. I haven't tested the branches, but on the face of it, it seems to be insufficient.

Maybe we should just do a redirect.

We can surely redirect the user to Special:Userlogin. The problem is that we will then loose all the various error messages logic which is handled in output page and just show a login page with no error message.

Created attachment 9530
(trunk) hide Title in returnto when it is unknown to the user

attachment hide_real_title_in_returnto.patch ignored as obsolete

I could not find any instances of the real title despite Tim said so. I tried using ?oldid= and ?curid= and the title never show up :-(

+ $this->context->setTitle( SpecialPage::getTitleFor( 'Badtitle' ) );

This only affects things that actually use RequestContext, you didn't set $wgTitle. I had an extension enabled which uses $wgTitle in a head script.

Created attachment 9539
(trunk) hide Title in returnto and set wgTitle when it is unknown to the user

and now setting wgTitle

attachment hidetitle_reset_wgtitle.patch ignored as obsolete

Created attachment 9540
(REL1_17) hides Title and wgTitle exposures. Bump MW to1.17.1

Patch for trunk applied to REL1_17


Created attachment 9542
Updated patch for trunk

Changes from Hashar's patch:

  • Rewrote the comments
  • The logic and comment in OutputPage.php didn't really make sense given that $this->getTitle() now returns Special:Badtitle for a private request, it doesn't return a private page title. Instead, unconditionally get the page title from the title parameter in the request.
  • Use Title::newFromURL() when processing the title parameter, for consistency with Wiki.php.
  • In SkinTemplate, fixed the returnto parameter in the login link, using similar code to OutputPage. It was pointing to Special:Badtitle. Still needs refactoring in a non-security commit, since the code is duplicated and $wgSecureLogin is (and was always) broken in OutputPage.
  • If there was no title in the WebRequest, don't send returntoquery without returnto. This is more consistent since nothing else in the chain supports returntoquery without returnto (LoginForm::successfulLogin(), OutputPage::returnToMain()).


Fixed in trunk with r104505, 1.17 in r104506, 1.18 in r104508 and 1.18wmf1 in r104509

t.glaser wrote:

For the record: does NOT affect 1.15, and the backported patch (in Debian’s package) does acutal harm. In 1.15 there is no information disclosure wrt. whether a page exists in this case.

1.15 is definitively affected by this, but it is not supported anymore, so the patch wasn't backported by us. What you are reporting concerns Debian’s
package that we don't manage. Please contact the reponsible for that package, we can't do anything about this.