Page MenuHomePhabricator

Introduce secure mode to MediaWiki
Open, Needs TriagePublic

Description

MediaWiki has a concept of elevated security mode for sensitive operations but basically all it does is just require going through authentication periodically. That makes an XSS or similar attack harder, but the techniques still work, it's just the window of opportunity that gets smaller.

Instead, we should aim for a secure mode that's actually more secure: while the user is in that mode, we should disable functionality that can serve as an attack vector, even at the cost of making the experience more inconvenient; and visibly mark in the UI that the session is in secure mode, and offer an exit action.

A couple things that we could do to lock down secure mode:

  • Disable custom JavaScript. We probably can't get away with disabling all of it, since some workflows involving sensitive functionality make heavy use of user scripts, e.g. steward or checkuser tools, but we should at least limit user-contributed scripts to the least insecure types, such as gadgets; and prevent the loading of user scripts belonging to different users, and scripts from another domain.
  • Make aggressive use of CSP.
  • Lock the session to the IP and user agent.
  • Disallow CORS requests (or at least make them not happen in secure mode).
  • On protocol-relative wikis, immediately exit secure mode if the user makes a request over HTTP.
  • Renew the session ID when entering. (I think we do this already but should be double-checked.)

There are a couple more things that relate to non-public tasks and won't be mentioned here; see backlinks.

Event Timeline

Tgr created this task.Dec 1 2018, 6:19 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 1 2018, 6:19 AM
Bawolff added a subscriber: Bawolff.Dec 1 2018, 6:22 AM

Disable custom JavaScript. We probably can't get away with disabling all of it, since some workflows involving sensitive functionality make heavy use of user scripts, e.g. steward or checkuser tools, but we should at least limit user-contributed scripts to the least insecure types, such as gadgets; and prevent the loading of user scripts belonging to different users, and scripts from another domain.

I have some doubts about how effective this is, but perhaps better than nothing.

Tgr added a comment.EditedDec 1 2018, 6:55 AM

I have some doubts about how effective this is, but perhaps better than nothing.

Banning scripts from other domains is easy to do via CSP and already makes the attacker's life significantly harder, as any attack scripts have to be set up on the wiki and so are easier to notice and analyze.

Non-ResourceLoader scripts in the local domain could simple be prevented from loading (ie. return an error on action=raw&ctype=text/javascript requests when the session has elevated security).

ResourceLoader is harder as load.php disables sessions so there is no way to handle it on that side (although I guess we could undo that if we really have to). Something something CSP hashes?

There is always the possibility of malicious browser plugins but it is probably entirely outside our ability to do anything about them.

Schnark added a subscriber: Schnark.Dec 1 2018, 9:14 AM

Looks like the Phabricator's high security mode, right?

Anomie added a subscriber: Anomie.Dec 2 2018, 1:04 AM

With how much people complain about the inconvenience of using 2FA, I suspect that disabling all their user scripts really won't fly.

With how much people complain about the inconvenience of using 2FA, I suspect that disabling all their user scripts really won't fly.

I like security and 2FA and I'd probably still complain about disabling all userscripts. Limiting them to only Wikimedia domains with CSP might be a better solution.

Tgr added a comment.Feb 2 2019, 8:22 PM

Suborigins would be a cool way to handle this. The spec is still in an early draft but something to pay attention to in the future.