Today

• No visible events.

Tomorrow

• No visible events.

Wednesday

• No visible events.

User Since

Oct 7 2014, 10:12 AM (611 w, 5 d)

Availability

Available

LDAP User

Grunny

MediaWiki User

Grunny [ Global Accounts ]

It's an extension, yeah, though we have some integrations into some shared pieces too, I'll see if I can split out a version that works on vanilla MediaWiki, otherwise will just share the code as is.

On Fandom, we've implemented a feature that allows only loading "approved"/"reviewed" JS script versions, including for cross-wiki imports. People can then temporarily enter unsafe mode during development to test latest versions of scripts. It may not be ideally implemented, but happy to run through it in case any learnings from it are helpful here.

Just making a note pre-emptively about making sure my access for Fandom security release management (and checking for reports in our bug bounty program with HackerOne) is maintained, as my account was caught up in the clean up in last year's one. Though I have MFA and will have commented here so I assume wouldn't be included.

Great, thanks @sbassett!

Was I caught up in this cleanup by chance @sbassett? I noticed my access seems to be gone. If so, could I be readded? I use the access for Fandom for pre-release access and checking for any crossover with our bug bounty program we run.

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 or at least .

@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 are passing the undefined variable as MW 1.23 is still using the boolean instead. The call to should also probably use a boolean instead of for consistency.

For the MW 1.23 patch for T108138, it looks like is undefined in the call as well, as it currently repeatedly calls rather than storing it in a variable.

I believe the patch for MW 1.23 related to T48143 will break as it adds the call to but the method does not exist in MW 1.23, as it is still using 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