Pine wrote:
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.
There is the https://phabricator.wikimedia.org/T71445 that talks about implementing code-review for JS and CSS.
Alex Monk wrote:
Trying to restrict it would probably lead to a backlash from communities that would make superprotect look like a joke. I suspect that if such a feature were proposed today, it would never be given to local users, but reserved for globally trusted people like developers. Local sysops are not necessarily (or maybe even usually) technically skilled, and communities do not appear to realise the amount of power that editinterface actually gives you, and that code written with it may frequently be executed by people with rights that the community would consider superior, like steward/oversight/checkuser/bureaucrat.
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 krenair@gmail.com:
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.
Trying to restrict it would probably lead to a backlash from communities that would make superprotect look like a joke. I suspect that if such a feature were proposed today, it would never be given to local users, but reserved for globally trusted people like developers. Local sysops are not necessarily (or maybe even usually) technically skilled, and communities do not appear to realise the amount of power that editinterface actually gives you, and that code written with it may frequently be executed by people with rights that the community would consider superior, like steward/oversight/checkuser/bureaucrat.
I would not tell them not to worry about it.
On Fri, 16 Mar 2018, 17:33 Leon Ziemba, musikanimal@wikimedia.org 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 eranroz89@gmail.com 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 z@mzmcbride.com 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l