Thanks @Ladsgroup! We'll patch it on our side privately.

In T278014#6935675, @sbassett wrote:

In T278014#6935629, @Grunny wrote:

Thanks, @sbassett ! Just for my reference on if I find any more of these in core or WMF deployed extensions, is it OK to push straight to Gerrit, and I assume we'd still want a ticket created for reference?

I would say likely, yes. However it's probably a good idea to continue filing these as private bugs so the Security-Team can review them (our weekly clinic meeting is Monday morning) just to verify they are indeed low-risk and to also time them well for the weekly train deployment, in getting pushed to gerrit.

Sounds good, thanks!

Thanks, @sbassett ! Just for my reference on if I find any more of these in core or WMF deployed extensions, is it OK to push straight to Gerrit, and I assume we'd still want a ticket created for reference?

Proposed patch:

Proposed patch:

Since this was fixed a while ago, should this bug be made public now?

Thanks for letting us know! Yeah, Gamepedia wikis are using it.

I see my name is on the list. I unfortunately haven't been as active as a volunteer for a while, but for some context, part of why I was originally given access here is related to my role at Fandom, providing early access to security releases for Fandom and Gamepedia so we can prepare and protect our user base quickly. I still use it for this purpose for each security release, and as we plan to launch a bug bounty for our wikis on Fandom and Gamepedia in the coming year which will include core MediaWiki (once we're on a newer MW version), I'd love to discuss collaborating more closely on it. :)

Hi @Yaron_Koren ! For the query being executed above, I'd suggest not doing the string replace with the quotes but instead using Database::addQuotes or at least Database::strencode.

@Bawolff this is great. One thought I had from looking at https://www.mediawiki.org/wiki/Reporting_security_bugs and https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Thanks is that they both only mention credit for vulnerabilities found in MediaWiki core or a bundled extension. I feel one missing part will be crediting those who report security issues in Wikimedia-deployed extension. These may not make sense to credit in the MW core CREDITS file as the issues weren't part of the code distributed in the tarballs, but it does seem worthwhile to also find a nice place to credit those who reported security issues that affected Wikimedia wikis such as through a deployed extension, as they're helping keep Wikimedia projects secure even if it's not an issue that is part of core or a bundled extension. What do you think?

Thanks, @Reedy! Found one more issue in the patches for MW 1.23. In the patch for T108138, the calls to getUserPermissionsErrorsInternal are passing the undefined variable $rigor as MW 1.23 is still using the boolean $doExpensiveQueries instead. The call to Title::userCan should also probably use a boolean true instead of 'secure' for consistency.

For the MW 1.23 patch for T108138, it looks like $user is undefined in the Title::userCan call as well, as it currently repeatedly calls $this->getUser() rather than storing it in a $user variable.

I believe the patch for MW 1.23 related to T48143 will break as it adds the call to parser::normalizeLinkUrl but the Parser::normalizeLinkUrl method does not exist in MW 1.23, as it is still using Parser::replaceUnusualEscapes instead.

@dpatrick Looks like https://gerrit.wikimedia.org/r/#/c/319055/ was merged in February and is now live, so I think this can be closed and made public once it's announced as part of the fixes released in T134863?

@dpatrick looks like the PoC https://www.mediawiki.org/wiki/Special:GlobalGroupPermissions?wpGroup=%3Cscript%3Ealert%28document.domain%29%3C/script%3E works again, did the patch get reverted?

Here's a quick patch to fix the issue:

I dunno, I think we could just set rel="noopener" on external links and document this.

That sounds like a reasonable response to me.

Just something to keep in mind, rel="noopener" only works on Chrome and Opera, and does not work in Firefox, Safari, IE, and Edge.

LGTM. :)

The backport patches for this to MW 1.23 and 1.24 should also use hash_equals in the check in the return of the method as well, i.e. here: https://github.com/wikimedia/mediawiki/blob/REL1_24/includes/User.php#L3939 and https://github.com/wikimedia/mediawiki/blob/REL1_23/includes/User.php#L3814. And they should both also probably have the same done for User::matchEditTokenNoSuffix.

The patches for T119309 in MW 1.23 and 1.24 should use hash_equals in the check in the return of the method as well, i.e. here: https://github.com/wikimedia/mediawiki/blob/REL1_24/includes/User.php#L3939 and https://github.com/wikimedia/mediawiki/blob/REL1_23/includes/User.php#L3814. And they should both also probably have the same done for User::matchEditTokenNoSuffix.

@Qgil @csteipp signed.

In T111029#1600822, @Krinkle wrote:

In T111029#1592348, @Grunny wrote:

Quick patch to URL encode the title:

T111029.patch951 BDownload

The problem is not lack of url encoding, it's lack of html encoding. URL encoding was also lacking, and doing that will fix certain current PageTriage bugs (e.g. some pages with quotmarks weren't working properly). But from a security perspective this isn't solved yet.

Quick patch to URL encode the title:

It looks like the patches were pushed to Gerrit and merged: https://gerrit.wikimedia.org/r/220839

There are some more vulnerable parameters not covered by that patch:

• https://wikitech.wikimedia.org/wiki/Special:CreateForm?template_foo=%22%3E%3Cscript%3Ealert%280%29;%3C/script%3E
• https://wikitech.wikimedia.org/wiki/Special:CreateForm?template_foo=foo&label_foo=%22%3E%3Cscript%3Ealert%280%29;%3C/script%3E
• https://wikitech.wikimedia.org/wiki/Special:CreateForm?add_field=1&new_template=%22%3E%3Cscript%3Ealert%280%29;%3C/script%3E