CVE-2022-34911: Username is not escaped in the "welcomeuser" message

**

CVE-2022-34911: Username is not escaped in the “welcomeuser” message

Closed, ResolvedPublicSecurity

**

• Edit Task

• Edit Related Tasks…

• Edit Related Objects…

• Mute Notifications

• Protect as security issue

• Award Token

• Flag For Later

If you create an account with some HTML in its name (which is not allowed by default, see T308465), after the account creation when it sets the page title to "Welcome, [username]" (using the welcomeuser), the username is not escaped: SpecialCreateAccount::successfulAction() calls ::showSuccessPage() with a message as second parameter, and OutputPage::setPageTitle() uses text().

Filing as a security task out of an abundance of caution.

Risk Rating

Low

Author Affiliation

WMF Product

• Task Graph
• Mentions

Event Timeline

Comment Actions

Untested patch that should fix the issue:

I can’t imagine we’d want to change

LoginSignupSpecialPage->showSuccessPage

for any reason. Similar to T308473, I’d imagine this could just go through gerrit.

Comment Actions

But OutputPage::setPageTitle() calls Sanitizer::removeSomeTags, is that not enough?

Comment Actions

But OutputPage::setPageTitle() calls Sanitizer::removeSomeTags, is that not enough?

For a lot of common XSS vectors, sure. But it’ll allow lower-level obfuscations and similar, minor CSS hacks, like: <span style=display:none>username</span>. I’m also going to guess that this bug was possibly found via phan-taint-check-plugin which I’m not certain adjusts any taints for Sanitizer::removeSomeTags. Which are all reasons why this is a very low-risk bug and really mostly code-hardening.

Comment Actions

But OutputPage::setPageTitle() calls Sanitizer::removeSomeTags, is that not enough?

For a lot of common XSS vectors, sure. But it’ll allow lower-level obfuscations and similar, minor CSS hacks, like: <span style=display:none>username</span>.

Yeah, better be safe. FWIW, “<” is not allowed in usernames unless you change the config, and “>” is forbidden regardless of config because it’s reserved for external usernames.

I’m also going to guess that this bug was possibly found via phan-taint-check-plugin which I’m not certain adjusts any taints for Sanitizer::removeSomeTags.

Actually… I created an account with “<” in its name for unrelated tests, and though I’d explore the interface a bit just to make sure that there was no obvious XSS around.

Comment Actions

This picked cleanly to all supported release branches. If those test fine, I’ll plan to merge them and this task can be resolved.

Reedy renamed this task from Username is not escaped in the “welcomeuser” message to CVE-2022-34911: Username is not escaped in the “welcomeuser” message.Sat, Jul 2, 7:40 PM

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL