In my opinion, such accounts should be globally blocked btw. It is a grave breach of trust and such accounts cannot be trusted anywhere else either. Thanks for playing, but goodbye for ever. DJ On Wed, Mar 14, 2018 at 3:42 PM, Brian Wolff <bawolff(a)gmail.com> wrote:

A restrictive script-src in a Content-Security-Policy (RFC <https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy>, T135963 <https://phabricator.wikimedia.org/T135963>) could have helped with this. Alternatively, a report-mode CSP could at least have brought this to global operators’ attention, though I don’t know if they would’ve been faster to react than the fawiki community’s seven minutes. Cheers, Lucas 2018-03-14 17:03 GMT+01:00 Amir Ladsgroup &lt;ladsgroup(a)gmail.com&gt;om>: -- Lucas Werkmeister Software Developer (Intern) Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de Imagine a world, in which every single human being can freely share in the sum of all knowledge. That‘s our commitment. Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

On Wed, Mar 14, 2018 at 9:14 AM, Jon Robson &lt;jdlrobson(a)gmail.com&gt; wrote: It's not particularly hard to with a browser extension, you just need to edit ResourceLoader (load.php) URLs and remove the 'user', 'site', 'ext.gadget.*' modules. Has this sort of thing happened before? Outside Wikimedia, plenty. http://www.bbc.com/news/technology-43025788 was one of the more high-profile examples. On Wikimedia wikis, well-intentioned but misguided uses of external scripts are not uncommon (back when I was a fairly new admin on the Hungarian Wikipedia, we included an AWStats counter in the page footer under an, uh, fairly liberal interpretation of the terms of use... the developers were not amused). As far as I am aware there was no malicious one.

Lego already did a script to verify no external resources are loaded: https://phabricator.wikimedia.org/T71519 I think there is a Jenkins job running it on regular basis On Thu, Mar 15, 2018 at 6:30 AM, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote:

Musikanimal, that sounds like a good suggestion to add to Phabricator. I hope that there is way that these suggestions are being tracked but I don't see a public task for this on the Security workboard, possibly to avoid announcing vulnerabilities in public until they have been assessed. Unless someone here has advice to the contrary, I think that going to Phabricator and submitting a new security bug, which will be nonpublic by default, would be a reasonable option. Pine ( https://meta.wikimedia.org/wiki/User:Pine ) On Fri, Mar 16, 2018 at 10:33 AM, Leon Ziemba &lt;musikanimal(a)wikimedia.org&gt; wrote:

Pine wrote: There is the https://phabricator.wikimedia.org/T71445 that talks about implementing code-review for JS and CSS. Alex Monk wrote: I don't think the communities actually want js injected without code-review that much. They (we) do want to have easy access to gadget and scripts though. Attempting to impose any procedure that messes with that access and/or does not give the communities final say in what is used will probably have a serious backlash. But if we could have a reasonable code-review that does not mean communities will not have access to gadgets and scripts, it will probably pass with most of the communities not caring. That does mean, in my view, that a lot of inexistent infrastructure needs to be created though, including a centralized code repo for js and css for the wikis, some interface to review code. What worries me most about such a change is small wikis keeping access to scripts and gadgets, it is already difficult for most of them to have access at the moment, the more hurdles we create the worse it will get. Arguably, automation is much more important in small communities than in large ones. Chico Venancio 2018-03-17 14:57 GMT-03:00 Alex Monk &lt;krenair(a)gmail.com&gt;om>: > You'd have to stop stewards from loading site-wide JS, gadgets, as well as > removing their ability to have their user JS from pulling in JS from other > sites/users/etc. somehow. > > > I would not tell them not to worry about it. > > On Fri, 16 Mar 2018, 17:33 Leon Ziemba, &lt;musikanimal(a)wikimedia.org&gt; wrote: > > > Sorry to slightly sidetrack this discussion, but someone recently asked > me > > if it were possible to modify a steward's user JS so that it granted them > > advanced rights like steward/checkuser/oversight. This of course is > > possible, but very rare since you need to be a sysop to edit these JS > > pages. The point this person was making to me however was that on smaller > > wikis it can be easy to become a sysop, and it's probable that by nature > > stewards will show up there occasionally, and that their own personal JS > > may not be closely watched. I told them not to worry about it, but if we > > really wanted to do something, we could make a steward's JS only be > mutable > > by other stewards (or something). > > > > Maybe something else to think about? > > > > ~Leon > > > > On Thu, Mar 15, 2018 at 5:46 PM, Eran Rosenthal &lt;eranroz89(a)gmail.com&gt; > > wrote: > > > > > Lego already did a script to verify no external resources are loaded: > > > https://phabricator.wikimedia.org/T71519 > > > I think there is a Jenkins job running it on regular basis > > > > > > On Thu, Mar 15, 2018 at 6:30 AM, MZMcBride &lt;z(a)mzmcbride.com&gt; wrote: > > > > > > > David Gerard wrote: > > > > >What ways are there to include user-edited JavaScript in a wiki > page? > > > > > > > > > >[...] > > > > > > > > > >You can't see it now, but it was someone including a JavaScript > > > > >cryptocurrency miner in common.js! > > > > > > > > > >Obviously this is not going to be a common thing, and common.js is > > > > >closely watched. (The above edit was reverted in 7 minutes, and the > > > > >user banned.) > > > > > > > > > >But what are the ways to get user-edited JavaScript running on a > > > > >MediaWiki, outside one's own personal usage? And what permissions > are > > > > >needed? I ask with threats like this in mind. > > > > > > > > There's an old post of mine that documents some of the ways to inject > > > > site-wide JavaScript: > > > > <https://lists.wikimedia.org/pipermail/wikimedia-l/2014- > > > August/073787.html > > > > > > > > > > > > > I believe, as Brian notes in this thread, that most methods require > > > having > > > > the "editinterface" user right so that you can edit wiki pages in the > > > > "MediaWiki" namespace. By default, this user right is assigned to the > > > > "sysop" user group, but if you search through > > > > <https://noc.wikimedia.org/conf/InitialiseSettings.php.txt> for the > > > string > > > > "editinterface", you can see that on specific wikis such as fawiki, > > this > > > > user right has been assigned to additional user groups. > > > > > > > > Jon Robson wrote: > > > > >It has always made me a little uneasy that there are wiki pages > where > > > > >JavaScript could potentially be injected into my page without my > > > approval. > > > > >To be honest if I had the option I would disable all site and user > > > scripts > > > > >for my account. > > > > > > > > You could file a Phabricator task about this. We already specifically > > > > exempt certain pages, such as Special:UserLogin and > > Special:Preferences, > > > > from injecting custom JavaScript. We could potentially add a user > > > > preference to do what you're suggesting. > > > > > > > > That said, you're currently executing thousands upon thousands of > lines > > > of > > > > code on your computer that you've never read or verified. If you're a > > > > standard computer user, you visit hundreds of Web sites per year that > > > each > > > > execute thousands of lines of untrusted scripts that you've never > read > > or > > > > verified. Of all the places you're likely to run into trouble, > > Wikimedia > > > > wikis are, in many ways, some of the safest. Given all of this code, > > your > > > > computer, as well as mine, are vulnerable to dozens of very real > > attacks > > > > at any time. And yet we soldier on without too much panic or worry. > > > > > > > > >Has this sort of thing happened before? > > > > > > > > Salon.com recently prompted users with ad blocking software installed > > to > > > > voluntarily mine cryptocurrency: <https://arstechnica.com/?p=1259653 > >. > > > > This situation on fa.wikipedia.org was obviously involuntary. I > don't > > > know > > > > of any similar incidents. We have had wiki administrators > inadvertently > > > > inject scripts with privacy issues, such as Google Analytics. These > > > > scripts have generally been promptly removed when noticed. On the > other > > > > hand, pages such as <https://status.wikimedia.org/> have been > loading > > > the > > > > same problematic scripts (Google Analytics and JavaScript from > > > > ajax.googleapis.com) for years and nobody seems to have cared enough > > > yet. > > > > > > > > >Can we be sure there isn't a gadget, interface page that has this > sort > > > of > > > > >code lurking inside? Do we have any detection measures in place? > > > > > > > > A much surer bet is that at least some gadgets and other site-wide > > > > JavaScript have privacy issues and potentially security issues. It > > would > > > > be shocking if, across the hundreds of Wikimedia wikis, none of them > > did. > > > > > > > > I think in the past Timo and maybe Alex Monk have done some surveying > > of > > > > public Wikimedia wikis using a browser or browser emulator to check > if > > > > there are network requests being made to non-Wikimedia domains. As > > Lucas > > > > noted in this thread already, there are also tasks such as > > > > <https://phabricator.wikimedia.org/T135963> that could be worked on, > > if > > > > there's sufficient interest. > > > > > > > > MZMcBride > > > > > > > > > > > > > > > > _______________________________________________ > > > > Wikitech-l mailing list > > > > Wikitech-l(a)lists.wikimedia.org > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > _______________________________________________ > > > Wikitech-l mailing list > > > Wikitech-l(a)lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

On a side note. Have we looked recently at decoupling the site wide JS/CSS rights from the edit interface right ? It has always seemed a bit weird to me that we had both these things in MediaWiki namespace, but the more we are closing down raw HTML in MediaWiki namespace, the weirder it becomes. Even if we would assign those rights to mostly the same groups, it would give some more healthy options in the long term. We've made a similar split in the user namespace (for much more practical reasons of course). But I think that shouldn't stop us from doing the same for global stuff.. We could even consider finding some way to detect raw html messages and have them subject to the same right.. We have https://phabricator.wikimedia.org/T120886 but i'm not sure if anyone gave it any serious consideration in the past 2,5 years.. DJ On Sat, Mar 17, 2018 at 6:57 PM, Alex Monk &lt;krenair(a)gmail.com&gt; wrote: