PHP Include Injection and Google Referral Hijack

Written by Mark Sanborn: Dec 3, 2008

So recently a friend of mine, had a client that had a very odd problem. His website was working fine when you go to it directly by typing in the domain name; however, if you searched for the site in Google and clicked the link for the site it would take you to a hijacked page.

So the page only appeared hijacked when the referral was coming from Google. The hijack could go unnoticed for months. You would either have to be googleing yourself or wait until a good samaritan sends you an email warning you of the problem. I must say this sort of attack is quite clever on the hijacker’s part. The hijacked page gets the original site’s page rank and Google visits while the site owner has absolutely no clue.

Fixing it

The first part of the problem was to fix the hijack. This was easily solved by simply deleting the .htaccess and restoring it with the original. The hacked .htaccess contained a redirect similar to something like this:

RewriteEngine On RewriteCond %{HTTP_REFERER} ^http://google\.com RewriteRule .* [R=301,L]

The second part of the problem was to find how the hacker was able to change the .htaccess. Since we don’t have access to shared hosting logs we were going to to have to do it the hard way.

We first tried a tool called, nikto. After running the tool it returned a myriad of potential problems that could have caused an attack, like old versions of PHP, old cgi scripts etc.. After thinking about it we thought that if it was the host’s fault there would be thousands of websites effected so we started digging into the code and found something interesting:


This one liner was the culprit we were looking for. This segment of code was used to include some code based on the particular pages the user was on. The problem with it however is that it blindly accepts any value here. Remember the golden rule: Sanatize all input! Failure to sanitize this input led to an attacker able to do something like this:

He would then have a script at his site called The attacker knew that they needed the .inc.php extension because the when they passed, ‘foobar’ through the page variable they got an error explaining that it wasn’t there. To prevent this knowledge you could supress the PHP error messages or use PHP required function instead and throw out a die statement. This would only provide obscurity however. We needed to eliminate the vulnerability with input sanitation.

To do this we used a simple regular expression that would only accept a-z and A-Z. This would prevent remote includes and path traversing.

function sanitizeInput($string) { 
    return preg_replace("/[^A-Za-z]/", "", $string); 

echo sanitizeInput('blah123');     

Remember to check over your code especially when getting input from the user. This is a very sneaky attack that would ruin your Google page rank and your traffic before you even noticed what was going on.

Need to print shipping labels on your site?

Checkout my product RocketShipIt for simple easy-to-use developer tools for UPS™ FedEx™ USPS™ and more.