4

We are recently seeing a number of external sites trying to leverage the core of EE to use our site to force referrals that look like they are coming from our domain. My assumption is they are trying this to juice up their referrals for search engine rankings. What they do is hit our site with URLs like:

http://www.macobserver.com/tmo/?URL=http%3A%2F%2Fexpressionengine.stackexchange.com%2F

This then redirects from our site to that external site. In doing some digging this is something built into the EE Core:

/system/expressionengine/libraries/Redirect.php

There is a check that stops the links from auto-redirecting with an interstitial page, but that is only a small bit of protection.

if ($force_redirect == TRUE OR ( ! isset($_SERVER['HTTP_REFERER']) OR !     stristr($_SERVER['HTTP_REFERER'], $host)))
{
    // Possibly not from our site, so we give the user the option
    // Of clicking the link or not

$str = "<html>\n<head>\n<meta http-equiv='Content-Type' content='text/html; charset=utf-8'/>\n<title>Redirect</title>\n</head>\n<body>".
        "<p>To proceed to the URL you have requested, click the link below:</p>".
        "<p><a href='".$_GET['URL']."'>".$_GET['URL']."</a></p>\n</body>\n</html>";
}

Is there a way to better prevent this kind of "referrer-jacking"?

Improve this question
1
  • Looks like this post has the suggestion of tweaking the HTACCESS to switch sending the '?URL=' type links to a 410 "GONE" page rather than a the 404. This seems more extreme than what I was looking for, but if that's what needs to be done… – Adam Christianson Dec 27 '13 at 14:57
2
+50

I know it'd be hacking core, but wouldn't throwing a rel="nofollow" attribute on the anchor negate the effectiveness of this?

Improve this answer
1
4

According to the bug reported by Mark Drzycimski, for those who don't have an Ellislab account, the solution is listed as follows:

In /system/expressionengine/libraries/Redirect.php on line 50, change:

"<p><a href='".$_GET['URL']."'>".$_GET['URL']."</a></p>\n</body>\n</html>";

to:

"<p><a href='".$_GET['URL']."' rel='nofollow'>".$_GET['URL']."</a></p>\n</body>\n</html>";

Improve this answer
3
  • You had the right idea and who knows when they updated that bug thread :) – Natetronn Dec 30 '13 at 20:08
  • So hacking the core is the official solution? Do we know if Ellis plans to roll this fix into a future release? I really hate hacking the core as it then requires me to remember to go back in and re-apply the fix after we update. – Adam Christianson Jan 2 '14 at 18:12
  • The bug on the ellislab.com tracker (support.ellislab.com/bugs/detail/20029) has been accepted and received official commentary, so I assume that something will be done… eventually. :-) – Mark Drzycimski Jan 2 '14 at 20:29
0

I can see two alternatives to this:

  1. Disable external linking. This would break various things like addon doc links in the control panel.
  2. Die rather than provide the external link when referrer != host. This is a much safer solution, but relies on your server providing valid referrer strings. Refreshing a redirected link that times out may also fail.

For solution #1 below line 39 which starts with:

$host =

add:

if ( ! isset($_SERVER['HTTP_REFERER']) OR ! stristr($_SERVER['HTTP_REFERER'], $host))
{
    die();
}

And for solution #2 below line 43 which starts

if ($force_redirect

add:

die();

In either case you could redirect to your homepage instead of just using die.

Edit: And as mentioned elsewhere the same idea can be accomplished via htaccess. The only real solution lies in an EE internal whitelist that automatically tracks valid external links. For example every time an addon is added any external URLs are added to the whitelist.

Improve this answer
0
<p><a href='".$_GET['URL']."' rel='nofollow'>".$_GET['URL']."</a>

Leeds to XSS vulnerability. Change to something like :

<a href='".htmlspecialchars($_GET['URL'])."' rel='nofollow'>".htmlspecialchars($_GET['URL'])."</a>
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.