Change Details

**There is an XSS in live fundraising banners on enwiki.** As per @Bawolff in T239778#5714105: > XSS in this banner: https://en.wikipedia.org/w/index.php?title=Talk:RandomPageThatDoesntexist&action=submit&section=new&preloadtitle=%3Cdiv%20class%3Dfrb%3E%3Cspan%20class%3D%22%25AVERAGE%25%22%20data-foo%3D%22%26lt%3Bscript%26gt%3Balert(%27XSS%20on%3A%20%27%20%2B%20document.domain)%26lt%3B%2Fscript%26gt%3B%22%3E%3C%2Fspan%3E%3C%2Fdiv%3E&nosummary=true&banner=scervantes_B1920_0701_enWW_dsk_p1_lg_template_share_inbanner&force=1&preview%00=yes > > Doing regexes on html and then re-inserting that html into the document is very very tricky to get right. I'd suggest instead using .text() on each text node and inserting with .text(), so the regexes get only done over text. If that's a complicated fix, adding an attribute like data-mw-banner to the outer div, and ensuring all selectors only select stuff that is decendents of that div (Since in MW users are not allowed to use attributes starting with data-mw) might be a short term fix to reduce the risk of users being able to set malicious dom elements. But switching to using .text() for the regexes is a much more reliable fix. The banner that this was found in was not live, but **others that have the same code, such as [[ https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/B1920_120502_en6C_dsk_p1_lg_cvt_cnt | this one ]], are live**. We need to fix this code ASAP, and including any banners that are not live, but that may get switched in to a campaign.

**There is an XSS in live fundraising banners on enwiki.** As per @Bawolff in T239778#5714105: > XSS in this banner: https://en.wikipedia.org/w/index.php?title=Talk:RandomPageThatDoesntexist&action=submit&section=new&preloadtitle=%3Cdiv%20class%3Dfrb%3E%3Cspan%20class%3D%22%25AVERAGE%25%22%20data-foo%3D%22%26lt%3Bscript%26gt%3Balert(%27XSS%20on%3A%20%27%20%2B%20document.domain)%26lt%3B%2Fscript%26gt%3B%22%3E%3C%2Fspan%3E%3C%2Fdiv%3E&nosummary=true&banner=scervantes_B1920_0701_enWW_dsk_p1_lg_template_share_inbanner&force=1&preview%00=yes > > Doing regexes on html and then re-inserting that html into the document is very very tricky to get right. I'd suggest instead using .text() on each text node and inserting with .text(), so the regexes get only done over text. If that's a complicated fix, adding an attribute like data-mw-banner to the outer div, and ensuring all selectors only select stuff that is decendents of that div (Since in MW users are not allowed to use attributes starting with data-mw) might be a short term fix to reduce the risk of users being able to set malicious dom elements. But switching to using .text() for the regexes is a much more reliable fix. The banner that this was found in was not live, but **others that have the same code, such as [[ https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/B1920_120502_en6C_dsk_p1_lg_cvt_cnt | this one ]], are live**. We need to fix this code ASAP, and including any banners that are not live, but that may get switched in to a campaign. Update: Also, since the XSS works with the preview feature, any existing banner, whether live in a campaign or not, exposes the site.

**There is an XSS in live fundraising banners on enwiki.** As per @Bawolff in T239778#5714105: > XSS in this banner: https://en.wikipedia.org/w/index.php?title=Talk:RandomPageThatDoesntexist&action=submit&section=new&preloadtitle=%3Cdiv%20class%3Dfrb%3E%3Cspan%20class%3D%22%25AVERAGE%25%22%20data-foo%3D%22%26lt%3Bscript%26gt%3Balert(%27XSS%20on%3A%20%27%20%2B%20document.domain)%26lt%3B%2Fscript%26gt%3B%22%3E%3C%2Fspan%3E%3C%2Fdiv%3E&nosummary=true&banner=scervantes_B1920_0701_enWW_dsk_p1_lg_template_share_inbanner&force=1&preview%00=yes > > Doing regexes on html and then re-inserting that html into the document is very very tricky to get right. I'd suggest instead using .text() on each text node and inserting with .text(), so the regexes get only done over text. If that's a complicated fix, adding an attribute like data-mw-banner to the outer div, and ensuring all selectors only select stuff that is decendents of that div (Since in MW users are not allowed to use attributes starting with data-mw) might be a short term fix to reduce the risk of users being able to set malicious dom elements. But switching to using .text() for the regexes is a much more reliable fix. The banner that this was found in was not live, but **others that have the same code, such as [[ https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/B1920_120502_en6C_dsk_p1_lg_cvt_cnt | this one ]], are live**. We need to fix this code ASAP, and including any banners that are not live, but that may get switched in to a campaign. Update: Also, since the XSS works with the preview feature, any existing banner, whether live in a campaign or not, exposes the site.