Special:Block associated IP addresses username validation
Closed, DeclinedPublicBUG REPORT
Actions

Assigned To

Authored By

	dom_walden
	Apr 26 2023, 6:18 AM

Description

What is the problem?

When entering a temporary username in the URL (i.e. Special:Block/<username>), as long as the username is in the correct format for a temporary account (i.e. *<anything>), we don't validate the username before sending the request to the temporaryaccount endpoint.

For example,

Special:Block/*foobar will make the request /w/rest.php/checkuser/v0/temporaryaccount/*foobar
Special:Block/*Unregistered_70%3Flimit=3 will make the request: /w/rest.php/checkuser/v0/temporaryaccount/*Unregistered%2070?limit=3 (the limit is applied)

I worry that this might be vulnerable to some sort of reflected XSS or cross origin attack. However, I haven't found any way to exploit this yet.

Steps to reproduce problem

Open browser devtools to the network tab
Go to Special:Block/*<anything>, for example:
1. Special:Block/*Unregistered_70%3Flimit=3
2. Special:Block/*Unregistered_99999999
3. Special:Block/*Foobar

Expected behavior: No request is made to /w/rest.php/checkuser/v0/temporaryaccount/...
Observed behavior: Request is made with the username you entered in the URL, which might return a 404 or other error

Environment

Wiki(s): MediaWiki 1.41.0-alpha (a8ab841) 01:43, 26 April 2023. CheckUser 2.5 (5b750d7) 17:37, 25 April 2023.

Related Objects

Mentioned In: T324719: In Special:Block, hide IP addresses associated with a temporary account, if there are too many
Mentioned Here: rECHU5b750d7dc748: Merge "Revert "Create group for assigning checkuser-temporary-account right""
rMWa8ab8413c9a5: Merge "actions: Update outdated/incomplete ActionFactory::getActionSpec docs"

Event Timeline

dom_walden created this task.Apr 26 2023, 6:18 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 26 2023, 6:18 AM

dom_walden mentioned this in T324719: In Special:Block, hide IP addresses associated with a temporary account, if there are too many .Apr 26 2023, 6:19 AM

Tchanders edited projects, added Anti-Harassment-Team (AHaT Sprint 29: The Ikseongwan); removed Anti-Harassment-Team.May 4 2023, 2:44 AM

STran claimed this task.May 4 2023, 10:39 AM

STran moved this task from Ready 🎬 (ONLY IF YOU HAVE NO MORE CODE TO REVIEW) to In Progress 💪 on the Anti-Harassment-Team (AHaT Sprint 29: The Ikseongwan) board.

Had a chat with @Tchanders about this and agreed that this was behaving as expected. A validation check is being run whenever the user to interact w/the UI as expected using the isTemporaryUser() check. That check is a little more permissive than the generator (afaik, to allow for flexibility in the username format) so *<anything> will pass that check and that's fine. We also can't stop the user from entering whatever they want in the URL and afaik that's being escaped by the framework so if that was going to be a problem, it'd probably be a problem for the entire API chain.

The case here, where the user has entered something weird and gets something weird in return is unfortunate but fixing it would require another API call to validate that the username is an account (not that it's a valid username because as stated, that's already being done) and that's a lot of overhead to commit to.

Will note that this problem can be resolved as a side effect if we ever go back to the usermultiselect widget, since that can be set to only take valid usernames and only call the endpoint for those valid usernames.

STran moved this task from In Progress 💪 to Done Q2 2022-2023 on the Anti-Harassment-Team (AHaT Sprint 29: The Ikseongwan) board.May 8 2023, 9:18 PM

Special:Block associated IP addresses username validationClosed, DeclinedPublicBUG REPORTActions