Contrib.social

Access bypass in entity-reference selection handler if hook_entity_access is implemented

Open on Drupal.org →
Created on 3 March 2024, over 1 year ago

Problem/Motivation

This was originally reported as a private issue and the security team decided it could be handled in public

When there is an implementation of hook_entity_access this is not taken into account by entity reference selection handlers.

Steps to reproduce

  1. Create a couple sample nodes.
  2. Protect one of these nodes by implementing entity access hook like follows.
    /**
 * Implements hook_ENTITY_TYPE_access().
 */
function HOOK_node_access(NodeInterface $node): AccessResultInterface {
  return AccessResult::forbiddenIf($node->id() == 1);
}
  3. Check that it works as expected
    /node/1 should return 403
    /node/2 should return 200
  4. Create an entity reference field to content for some content type
  5. Configure the select list widget for that field
  6. Open "Add node" form for that content type
  7. At this point you should be able to see the label of "protected" node in the select list

    8. The issue also happens when autocompletion widget is used.

    Proposed resolution

    When there is no access to 'view label' for a result, show Node: 3 or similar - e.g. {Entity type label}: {Entity type id}

    Remaining tasks

    User interface changes

    API changes

    Data model changes

    Release notes snippet

🐛 Bug report
Status

Active

Version

11.0 🔥

Component
Entity  →

Last updated about 5 hours ago

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

  • Issue created by @larowlan
  • Comment 4 days ago →
    🇸🇪Sweden peter törnstrand

    Reproducing the problem by following the steps outlined I can also see the node label in the content overview view (/admin/content) although the label is not linked to the node.

    The only entity that defines a "view label" permission is Taxonomy with the "view vocabulary labels" permission. Do you propose we introduce a new "view node labels" permission? Should there also be "view block labels", "view user labels"?

    As anonymous user I can see the "label" of a user.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024