10.1. Step 1: Secure the Menu

The first step to fixing this module will be a vastly modified hook_menu. Currently, each menu entry is available to any user with the access content permissions—which means it is usually available to anyone, including anonymous users. Table 10-1 shows each menu entry and a proposed change. After the table you'll look at some specific code changes.

Table 10.1. Updates to Menu Items to Make Them Secure
PATHPOSSIBLE ACTIONS
/vulnerableThis entire functionality could be removed or at least protected with a more limited permission like administer site configuration.
/session-switcherThis highly abstract menu callback may be fine with the permissions it has.
/insufficient-authenticationThis should probably be given its own permission via hook_perm, which would then need to be inserted into the access arguments.
/log-in-sql-injectionThe purpose of this callback is to let users log in as another user. So, if anything, this should be changed to a more permissive rule so it will work on sites where anonymous users cannot access content. However, logging in with username and password in the URL is not recommended because it makes it easier for a malicious user to gain access to the site. Thus, this feature should simply be removed, and the site will have to find an alternate solution.
/show-me-the-dataThis user-search capability should probably be protected by the search content and access user profiles permissions.
/csrf-disableIn general users should be disabled ...

Get Cracking Drupal®: A Drop in the Bucket now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.