Pathauto and Global Redirect defaults expose usernames and more

FYI as a security team member I can vouch this was voted to be addressed publicly.

So the problem with this security issue is:
1. The person still has to know the node ID.
2. This kind of situation is not limited to Global redirect. It also can happen with:
a. Path redirect: someone creates a redirect to node/[inaccessible-node-id] and the user is redirect to the URL alias of the node
b. Pathologic: someone links to node/[inaccessible-node-id] in filtered text, the URL is converted to its URL alias.

The primary problem is the use of URL aliases. We made a big step in Drupal 7 with an Entity API, but currently our URL aliases are *not* tied to entities. Once we can add {url_alias}.entity_type and {url_alias}.entity_id plus a generic entity API, it should be a lot easier to be able to check access to an entity based on its URL alias.

Back to the original problem with Global redirect. We have an option to check menu access, but its disabled by default and doesn't have a good description. The reason its disabled by default is because it is a pretty significant performance hit on every single request, plus according to the original comments, "Use of menu_get_item should be optional as it appears in some situations it causes WSOD's."

subscribing

subcribing

subscribing

So basically this looks like we need to work on the Menu Access check side of GR for those who are bothered about exposing username's via the URL.

Bare in mind, the URL will be cleaned using PathAuto so the URL may not always be a 100% representation of the username (symbols removed, spaces switched for hyphens, etc).

I also think this can be a security/privacy issue. Some users might use their real name or e-mail address as username.

Also when a username is not exposed it will be harder to hack an account and gain access.

Matt - it was, at one point, enabled by default however some people found this cause WSOD's so the feature was disabled by default...

tomsm - if it were an email, it would at least be partially cleaned up by PathAuto. Besides, the username is also printed on most posts around the site (thus exposing the name). If people are really that bothed about exposing a username, why did the site admin bother setting up the URL aliases to begin with?

My site is an online catalog.
I do not allow users to post any content or comments, they can log in to view certain CCK fields (= prices, download links).

The URL aliases for the products are very handy (SEO, etc.).

But for the user that is logged in, the user aliases are less important.

Maybe I should disable automatic aliases for users to solve this problem?

Well if user profiles are private (particularly to the point where you're worried about a "hacker" retreiving a username by seeing where user/123 redirects to) then aliasing them for SEO reasons seems rather pointless.

This is where my problem kind of lies... The reason people tend to URL alias the user profiles is often for SEO reasons, however if the profiles are SO private that you need them locked down as described above, then aliasing them is rather pointless. At that stage it is less of a module security issue and more of an administrative configuration issue.

However I can see that for a private community, it might be handy/easier to type in "user/tom" rather than "user/14363"... But you can't always rely on the URL mimicing the User Name - Path Auto will clean out any non-url friendly characters (spaces, symbols, capitals, etc) which therefore means you cannot simply type a username into the URL and garuntee it'll go to the user profile.

When I logged out of my site as admin, the screen would be the same as when I am logged in, But if I tried to access any admin menu etc, drupal would say
Access Denied...
In effect, when I clicked ''log out'', I was actually logged out- but the screen still was still the login screen.
I after several hours of this, I removed Global redirect, and everything went back to normal log out / log in.

Eddison - that is not related to this issue. Besides, I cant see how GlobalRedirect would cause that - sounds more like a browser caching issue to me...

Hi Nicholas,

Thanks for taking the time.
Your nearly right mate ! Nothing to do with and humble apologies to global re-direct !!
It was a very peculiar problem- I would get the wsod (white screen of death) or Fatal error etc.
Access denied you are not authorized to view this page.
But i was getting different things happening at different times. And once i removed global re direct, everything went back to normal??
Then several hours later, it happened again- wsod.
Even tried to modify the php.ini, .htaccess, and settings.php lots of different ways.
I have a sub domian, and thought it was that- http://art-magi.com/kilnwizz iow the subdomain was causing the problem. Then i took DRASTIC measures- re-installed the site, brand new not from a backup. holy hell!! talk about pain lol !
Same thing started to happen again!
I installed a module called drupal tweaks and tried to change the php.ini file, and it told me it could not be changed. It is set to 32mb. As i installed ubercart, all the memory was being used.
The host people namecheap upped the php.ini memory to 64mb and now everything is fine.

Humble apologies to global_redirect!
I re installed it- thanks so much for this great program

Ed

subscribing

I'm gonna move this to Postponed as, since tomsm's reply (#9) there has been no further discussion and, at the moment, my personal opinion on this is that it's more of a site-config issue rather than a module security issue.

This is disclosing node titles in the default configuration of Pathauto and Global Redirect. The fact that it's not easy to fix should not mean that can't be addressed in this module. Of course the entity ids need to be known previously but these are predictable.

Hello, I was wondering about what is status on this now? :)

Hello,

I am not planning to spamming this, but I just would like to know if there is any plan to correct this issue? Or will this be like "closed (won't fix)?

@truls1502

It's a configuration issue, as suggested in #9. This is what you have to do:

• Go to /admin/config/search/path/patterns and delete the entry at the page bottom in the User path section
• Switch to /admin/config/search/path/list/user/ to see all your entries for the last time
• Go to /admin/config/search/path/delete_bulk and bulk delete all user alias paths.

Alternatively go to the database and query

SELECT * FROM `url_alias` WHERE `alias` LIKE `users/%`

Delete all entries in question. Or replace SELECT in your query by DELETE if you did not want to see first what you're going to do.

I think this is annoying, maybe someone of the Drupal security team could describe how one could NOT script url requests, get the user names and guess on passwords. There have been security updates for less. I would at least set a message describing possibly unwanted misconfiguration.

Hello All,

You can use https://www.drupal.org/project/m4032404 module to redirect from "Access denied" to "Page not found". Hope this helps

#tomsm and #upunkt: Thanks for suggestion fellows. For me users aliases are not important so removed pathauto default users paths and performed bulk delete all user alias.

I feel Global redirect module provide warning on website status page regarding this behavior which is sufficient for users to think whether to enable Menu Access Checking setting or not.

I'd suggest that the way to address this is to add a README to Global Redirect.

Thanks for the patch. But there is already a README.txt instead of a README.md. I've added the proposed text to that file.

... would it make sense to change the default setting for Menu Access Checking to "Enabled"? The help text for that field mentions avoiding "unexpected behaviour" but it's not clear what that behavior might be.

I agree with the original Issue Summary. I think Menu Access Checking should be enabled by default, to be on the safe side. If it's disabled, you can easily disclose the administrator user name:

Go to /user/1 which redirects to /users/mysecretadminname