If you configure it such thta only logged-in users can read it, then alllwing previews would leak its contents for logged-out users, no?

I've faced this issue when my browser didn't send a Referer: https://wikipedialibrary.wmflabs.org/ header when accessing https://search-ebscohost-com.wikipedialibrary.idm.oclc.org/login.aspx.

In T392341#10768063, @STran wrote:

I wonder if we can use the election ID as a part of the edit token salt, akin to rollback

Does it? I skimmed the buildRollbackLink function and it looks like it just passes rollback as the salt.

I wonder if we can use the election ID as a part of the edit token salt, akin to rollback

Sumimasen! Watashi will try to twanswate it ^^;

Hello everynyan!

I was reading the SecurePoll source code, and found some oopsie-whoopsies!! Therefore, I want somenone to fixie-wixie the problems (* ^ ω ^)

First off, ArchivePage.php and UnarchivePage.php do not check if the request is POSTed or has an edit token, so an eeeevil attacker can convince an election admin to archive or unarchive a page without their intention O.O

Additionyally, if one of the options for a single transferable vote with Droop quota poll is an cross-site scripting payload, such as <script>alert("OOPSIE WOOPSIE!! Uwu We made a fucky wucky!! A wittle fucko boingo! The code monkeys at our headquarters are working VEWY HAWD to fix this!")</script>, then a voter would get XSSed if they voted for the malicious option OwO
This problem is caused by line 432 of VotePage.php :3

And also, VoterEligibilityPage#executeClear() does not check if the request is POSTed or has a valid edit token, thus also leading to the first problem (︶︹︺)

I also saw that SetTranslationHandler.php doesn't validate that the user is an election admin, so an arbitrary user can change the text for an poll, even if they're not logged in! (⌒_⌒;)
Luckily, this functionality seems to be broken since MediaWiki 1.43, as it cannot properly get the request body and instead reports No valid body (o^▽^o)

Lastly, the functions ResultPage::getPagesTab() and ResultPage::getErrorsTab() does nyot escape user input!! So if a malicious user can sneak in a malicious page name, this can happen:

Fortunately, the impact of this problem is reduced due to two things:

• All but one of the cross-site scripting vulnyable areas are inside elements' contents, which cannot contain the left-angle bracket or the right-angle bracket since it's a title 💮
• Thus, the one vulnerable area is inside tha attribute of an element. However, it depends on SetTranslationHandler.php to work to display, which we have already established doesn't on MediaWiki 1.43 🩷

Eto... I have one question, nya. For some reason, the edit token is checked when voting, but the request is still allowed if it's a CSF O.O
Instead, the scrutiners have to vawidate that the CSRF flag is not unset! I want to ask if you know the answer (＃＞＜)

That's all :3

https://www.mediawiki.org/wiki/LUAREF#frame:getTitle:

Returns the title associated with the frame as a string

Is there a way to reenable WebAuthn on auth.wikimedia.org right now? Or is it something to be planned in the future

I suppose so :p

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AJAXPoll/+/1130013

I suppose this can be implemented as a content handler? This would give us validateSave() to check types, and preSaveTransform() to also change icon_width to an integer if we so wish

I have this exception after loading only Skin:Vector (b8febf782b5291d85c0d7a5f97fca9fd1b21abac), Extension:OOJSPlus (ec0a1051aa8c001c0bec22daf3d05d7c6c2d483b), and Extension:SimpleBlogPage (3d9ee78dfe360077da076cd7e00275f79b506d15, along with a local modification to extension.json to add "load_composer_autoloader": true to load composer dependencies):

MediaWiki internal error.

LGTM

We have to subscribe them to security tasks anyway because of the default view policy

I only need it for REL1_43, but I personally try to backport every change I make (to versions that have not reached their end-of-life). Should I not?

In T383390#10474442, @cicalese wrote:

Reopening since the patch was only applied to the Release 1.42 branch. Was it fixed in another patch on master and the Release 1.43 branch?

Personally, I tried to take a stab at it when I first filed it, but it was too complex for me to figure out.

Adding data-nosnippet to the relevant element should work, and it appears to work as Core also does that (T315259: Add data-nosnippet to the printfooter div, T353984: Sitenotice can appear as the preview in search results on google).

I've been added to Trusted-Contributors.

In T376267#10466287, @Ladsgroup wrote:

ladsgroup@mwmaint2002:~$ mwscript extensions/CentralAuth/maintenance/createLocalAccount.php --wiki=labswiki  "BlankEclair"
DEPRECATION WARNING: Maintenance scripts are moving to Kubernetes. See
https://wikitech.wikimedia.org/wiki/Maintenance_scripts for the new process.
Maintenance hosts will be going away; please submit feedback promptly if
maintenance scripts on Kubernetes don't work for you. (T341553)
User 'BlankEclair' created

Try again please.

You're welcome ^_^

FYI, my trinklets page lists all public vulns I've found. As of writing, all but one (NeoChat) are MediaWiki extensions or skins

The bug still happens without Extension:DisplayTitle:

Should this task be closed?

i have no idea how my time management works

oops forgot a trim