We were diagnosing an issue on officewiki and realized that the parsoid CLI interface can access content on officewiki, despite it being private. This isn't unexpected; the CLI doesn't have any permissions checks (as far as I know).
But I went looking for permission checks in the REST interface (ParsoidHandler) and couldn't immediately find anything which seemed to implement permission checking. In contract, ApiVisualEditor::execute in VisualEditor has pages and pages of permission checks sitting ahead of the parsoid request.
If the checks are missing, it isn't generally user-exploitable, since our network partition is (deliberately) such that Parsoid's REST API is not externally accessible. RESTBase sits in front of Parsoid -- so any protections in RESTBase cover Parsoid.
However: 1) wikitech exposes the Parsoid API for that wiki, and 2) the 1.35 LTS release has a zero-conf setup for VisualEditor which exposes the Parsoid API on third-party wikis.
It seems that we could use a speedy security review here to ensure that the Parsoid REST API doesn't:
- For private wikis (login-required), doesn't expose page content w/o proper authentication
- For wikis in general, doesn't expose content which should be subject to per-user restrictions (is that a thing?)
- For wikis in general, doesn't allow edits which should be subject to per-user restrictions
This could be a false alarm; I don't have enough familiarity with the REST API infrastructure to know where permission checks "ought" to be done, so they could be sitting there (or part of the infrastructure) and I'm just not seeing them. But I'd appreciate a second look.