Page MenuHomePhabricator

i18n XSS audit in GrowthExperiments
Closed, ResolvedPublicSecurity

Description

Steps to reproduce:

  1. set MediaWiki:Growthexperiments-homepage-suggestededits-tasktype-machine-description to <script>alert('xss')</script>
  2. visit Special:Homepage on desktop (or visit it on mobile and then click on the "Suggested edits" box)

(via TaskTypeSelectionWidget)


Same for growthexperiments-homepage-suggestededits-pageviews (via SuggestedEditCardWidget); only on desktop (and for certain tasks).


Same for growthexperiments-addlink-summary-column-header-linked, growthexperiments-addlink-summary-column-header-suggestion and growthexperiments-addlink-summary-title (via AddLinkSaveDialog); seen when opening an Add Link task from the homepage and opening the save dialog.


Steps to reproduce:

  1. set MediaWiki:Growthexperiments-homepage-suggested-edits-header to <img src="http://example.com" onerror="alert('xss')" />
  2. visit Special:Homepageon mobile
  3. click on the box with <img src... on top

Event Timeline

Also growthexperiments-homepage-suggestededits-pageviews (via SuggestedEditCardWidget). Probably not worth creating a new task for each message.

Also growthexperiments-addlink-summary-column-header-linked, growthexperiments-addlink-summary-column-header-suggestion and growthexperiments-addlink-summary-title (via AddLinkSaveDialog).

Tgr renamed this task from i18n XSS in GrowthExperiments TaskTypeSelectionWidget to i18n XSS audit in GrowthExperiments .Jan 4 2022, 9:11 AM
Tgr updated the task description. (Show Details)
Tgr updated the task description. (Show Details)
sbassett moved this task from Incoming to Watching on the Security-Team board.
sbassett subscribed.

LGTM.

+1. Do we want to be extra-careful and security-deploy this patch? Or can it get merged later on a Monday for the week's train? We've definitely done the latter for several msg-related XSS vulns like this in the past. I personally feel that's fairly low-risk, given the need for an attacker to either be able to edit pages under the MediaWiki namespace or push/merge patches to this extension's repo.

Do we want to be extra-careful and security-deploy this patch? Or can it get merged later on a Monday for the week's train? We've definitely done the latter for several msg-related XSS vulns like this in the past. I personally feel that's fairly low-risk, given the need for an attacker to either be able to edit pages under the MediaWiki namespace or push/merge patches to this extension's repo.

I'm happy to follow whatever is considered best practice (agreed it's low-risk) - will merge next Monday then.

Merged & backported to wmf.17 (missed the branch cut first due to some CI shenanigans): rEGREc7ae734fb063: SECURITY: Fix several i18n XSS issues in suggested edits Also includes the fix for T298019: i18n XSS in GrowthExperiments suggested edits pager (CVE-2022-28326). I think this task is done.

Merged & backported to wmf.17 (missed the branch cut first due to some CI shenanigans): rEGREc7ae734fb063: SECURITY: Fix several i18n XSS issues in suggested edits Also includes the fix for T298019: i18n XSS in GrowthExperiments suggested edits pager (CVE-2022-28326). I think this task is done.

Thanks. I suppose this and the related task can be resolved and made public, since the related patches are in gerrit.

Tgr claimed this task.

Thanks. I suppose this and the related task can be resolved and made public, since the related patches are in gerrit.

Resolved. I don't think I have the right to make them public.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Low.