Page MenuHomePhabricator

Introduce secure mode to MediaWiki
Open, MediumPublic

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

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.

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.

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

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.

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.

Also, I wonder how well that would work for users in places where ISPs do change between IPs at a high rate. Some people on enwiki have said that some ISPs in the United Kingdom can cycle through several IPs in the same minute.

chasemp triaged this task as Medium priority.Dec 9 2019, 4:35 PM

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.

FWIW, not sure what i was thinking when i wrote this. Maybe i read it fast and was assuming that secure mode would only apply to secure pages, and non-secure pages would still be allowed with lax rules (like the current disable user scripts), which i think is pretty ineffective.

Having a secure mode that's entered for all requests until its exited, does seem much more secure. There can still be issues if the user has an old tab open from before entering secure mode, but this would still be a big step up.

I think to make this acceptable to users though, it would have to be very limited at least initially. e.g. only for changing your password or other very rare actions.

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.

Honestly, I'd like to do that just generally :)