getgrav/grav-plugin-flex-objects: Flex Objects API serves pages without the Pages API permission checks
What fixes it
- 1.4.17getgrav/grav-plugin-flex-objects, composerGitHub
composer require "getgrav/grav-plugin-flex-objects:^1.4.17"
A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.
Description
Summary
The Flex Objects plugin provides generic API routes for every enabled Flex directory, including the built-in pages directory (/api/v1/flex-objects/pages/...). Those routes checked only the directory-level admin.pages.* permission. They did not apply what the Pages API (/api/v1/pages/...) applies to the same content: the api.pages.read and api.pages.write permissions and the page's own permissions rules. A signed-in, non-super account with API access could read, change or delete pages that the Pages API refuses it.
Affected versions
Flex Objects 1.4.0 through 1.4.16, on Grav 2.x with the API plugin enabled. The pages Flex directory is enabled by default. Sites that rely on page-level permissions rules are affected when running API plugin 1.0.16 or later, the first version where the Pages API enforces those rules.
Details
FlexApiController authorizes list, read, create, update, delete and media requests against the permission prefixes declared in the directory blueprint. For pages those are admin.pages and admin.configuration.pages. Once that check passed, the requested page was returned, saved or deleted with no further check.
The Pages API authorizes each request per page: a rule in the page's permissions frontmatter (or an inherited one) that denies the action is final, and otherwise the account needs api.pages.read or api.pages.write. None of this ran on the generic route, so:
- an account denied by a page's own rules could still read the page's Markdown and frontmatter, overwrite its content, and delete it;
- an account holding
admin.pages.*but noapi.pages.*permission could do the same to any page; - because permissions resolve through parent keys, an account holding only the pages configuration permission (
admin.configuration.pages) was treated as holding page read, update and delete.
The original report covers the first case. The other two were found while confirming it. The account needs api.access and one of the permissions above. Super users already hold these capabilities.
Impact
A non-super account can read page source and frontmatter that is never rendered, change what a page publishes, and delete pages, in each case for pages it was explicitly denied or was never granted. The impact is limited to page content. It does not give access to accounts or configuration, and it does not let the account turn on Twig processing for a page.
Patches
Fixed in Flex Objects 1.4.17. Pages are no longer served by the generic Flex Objects API routes. Requests to /api/v1/flex-objects/pages and below return 403, and pages are read and written only through the Pages API. API clients that used the generic route for pages need to switch to /api/v1/pages.
If you cannot update right away, remove admin.pages and admin.configuration.pages from non-super accounts and groups, or remove api.access from accounts that do not need the API.
Credits
Reported by @ffasterss and @shirabe0x05 of Omoikane Labs.
Text from GitHub Advisory Database
Affected versions 1
- getgrav/grav-plugin-flex-objects, composer>= 1.4.0, < 1.4.17GitHub