If anyone knows a site is Drupal-powered (pretty easy to find out), a malicious person(s), or competitor, could cause significant damage to the search engine rankings of said website simply by linking to it from other multiple external websites and including a word into the url.

Example:

www.example.com/articles -- Intended URL

www.example.com/word/articles -- Malicious URL

(Note: Tested only with Clean URL's and Pathauto enabled)

I have tested for this vulnerability at a number of high-profile Drupal-powered websites and was able to access a duplicate page of the intended page (and sometimes un-intended too - though not sensitive) in all cases, using an alternative form of the path.

On some of the tested sites, words inserted into certain parts of the (directory) path lead - correctly - to "Page not found" but it was only a simple matter of trial and error to find the vulnerable "path-part".

One could further "intensify" the attack by simply adding further un-intended directories within the path to exacerbate the problem.

It may even be feasible (in theory at least) to "shift" the ranking of a page/site to rank for terms completely un-related to its niche.

This constitutes a serious, and potentially significant financial vulnerability to any Drupal sites whose livelyhood is reliant upon search engines that employ duplicate content filters (most that matter these days), and/or for sites attempting to raise awareness of its cause/mind-share... To most sites, it's as good as taking a site down.

I know this topic has loosely been raised around the forums but it was only after debugging a path issue of my own did I discover the breadth of the problem which I don't believe has been picked-up before.

Clearly, once a path has been created - by whatever authentic means - the system should only then allow access to that page, via that intended path.

(I'm assuming it's a Path module issue, move if necessary).

Comments

Nick Lewis’s picture

Nick Lewis commented

Are you certain that this isn't a pathauto issue? Most users aren't that verbose in creating paths.

eagereyes’s picture

eagereyes commented

Could you name a specific URL or path after the hostname where this would occur? I don't have a /articles, and I haven't been able to reproduce the problem. Also, I don't see how pathauto could be responsible for this, but it would of course be interesting to deactivate it for a short time to see if the effect is still there.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Project: Drupal core » Pathauto
Version: 4.7.3 » 4.7.x-1.x-dev
Component: path.module » Code

I don't really get this bug report, but I can't reproduce with core, so re-assigning to pathauto module.

Compare:

http://drupal.org/handbook

with:

http://drupal.org/silly/handbook (404, as expected)

I'd check your pathauto rules to make sure something isn't out of whack.

TheWhippinpost’s picture

TheWhippinpost commented

I wrestled with the "ethics" of "exposing" an existing website but I'm not sure the owners would exactly thank me for it... Particularly if it was a clickable link Goolgle found! I can say however, I've tested against at least one of the contributors to this thread (at the time of writing)... if that helps ;)

I suppose I can say I've tested it here without giving away a URL pattern, and it worked.

It seems from my small test sample that some sites are more exposed than others - By that I mean, one site may have more vulnerable path-patterns than another.

I should add (in hindsight), that my assertion of testing against clean URL's and Pathauto cannot be qualified because I don't know if a vulnerable site is using Pathauto... More accurately, I meant that those were enabled for my test site. Sorry for the confusion.

Remember, trial and error will probably yeild results - I only tested a handful of sites and each one was found to be vulnerable within 2-3 attempts... most only needed one!

TheWhippinpost’s picture

TheWhippinpost commented

In fact, what I'll do is email the contributor alluded to above with an example URL (assuming I can find the contact form)... Look out for my sig within the next 10-15 mins. HTH

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

It doesn't have to be a "real" URL. We just need some detailed steps on how to re-produce the bug.

Ex:

Step 1. Create a node
Step 2. Give node a path like "apple"
Step 3. ????
Step 4. Go to http://example.com/foo/apple and observe how you're taken to the page at http://example.com/apple.

TheWhippinpost’s picture

TheWhippinpost commented

Real examples have been sent to the relevant person/persons/organisation/entity/body/what-have-you

TheWhippinpost’s picture

TheWhippinpost commented
Project: Pathauto » Path
Version: 4.7.x-1.x-dev »

After further thought, I'm tossing this back to the Paths module because I don't believe 2 of the sites tested have Pathauto installed, judging by the URL's. This looks like a problem that affects Pathauto, rather than one of Pathauto's doing.

I'm not sure what time it is where the recipient(s) of my example emails reside but I suspect it's prolly (very) early hours there ATM.

WebChick asked for a way to reproduce the error. All I can say is; If I was any more explicit, it would be tantamount to aiding & abetting.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

As this "vulnerability" is not of data but of ranking in search engines, I don't mind sharing the details when it comes to my site.

There are certain URLs in pathauto which take the last argument in as an argument to a query to find any path that begins with that term. That section of code was actually the source of the XSS vulnerability fixed back in August. Very few people use this feature, but it can be used like this: http://knaddison.com/pathauto/node/fon Notice how that page brings back every path where the dest begins with fon% You can also visit http://knaddison.com/pathauto/node/stuff/fon and get back a page (not a great one, but still a page). The code for that is at the end of pathauto_node.inc I would LOVE to remove that functionality because I don't see a purpose for it. I haven't removed it simply because there are people who use it on their sites (link to google search for inurl:pathauto/node). I do plan to remove it in 5.0 and have a BIG RED WARNING that if people need functionality like that they either create a new module to do it or use taxonomy/term/X listings instead. If others feel this is sufficiently important then I would be more than happy to remove that feature from Pathauto.

I understand from Heine that this affects more than pathauto - I just wanted to clarify the places in pathauto that offer this behavior.

TheWhippinpost’s picture

TheWhippinpost commented

I believe this issue has unpublished but for those concerned and able to read, I might be worth repeating something I've already informed Moshe about...

For pages with relative links, consider that they too will have incorrect paths too. In essence, this could mean an even easier job for an attacker by simply targetting the home-page: Where a root page has teasers and pager links to all content, the bot will swallow!

I've raised the subject of absolute paths elsewhere and whilst I fully appreciate both sides of the argument, given that Matt Cutts (of Google) himself has recommended them, and again, with the stakes being so high these days for many site-operators, I remain sold on the belief that there should be no room for doubt WRT paths = absolute.

robertdouglass’s picture

robertdouglass commented
Status: Active » Closed (duplicate)

I wrestled with the "ethics" of "exposing" an existing website

This sounds suspiciously like blackmail. I hope for your sake that the wrestling match wasn't too protracted.

This is a duplicate issue of http://drupal.org/node/74347. Please track the issue there where real code is being considered without added rhetoric.

TheWhippinpost’s picture

TheWhippinpost commented

This sounds suspiciously like blackmail. I hope for your sake that the wrestling match wasn't too protracted.

This sounds suspiciously like both paranoia and a threat.

I suggest that if you have any concerns regarding my personal motivations, that you rasie them with myself offline and not pollute this thread with suppositions.