Off topic

[Roger]

Realising this is off topic from WHMCS. But we do seem to have a family of sorts here. So I though I would throw this out to the crowd. May help some one.

 

Has anyone experienced a "302 Redirect" (possibly has multiple names, it's an old exploit) page(s) hijacking yet? One of my unused reseller sites and 3 clients were hit with this over the weekend. If you have had to deal with this aggravation. Let's compare notes here.

 

Matt, perhaps a forum where we can help one another with just plain old webmaster issues would be good for the WHMCS community. What do you think?

 

Regards,

-Roger

[Matt]

Yeh ok, I'll set one up shortly - quite a few web hosts visit here daily so you should get some responses soon.

 

Regards,

 

Matt

[Adam]

What is it?

A page hijack is a technique exploiting the way search engines interpret certain commands that a web server can send to a visitor. In essence, it allows a hijacking website to replace pages belonging to target websites in the Search Engine Results Pages ("SERPs").

 

When a visitor searches for a term (say, foo) a hijacking webmaster can replace the pages that appear for this search with pages that (s)he controls. The new pages that the hijacking webmaster inserts into the search engine are "virtual pages", meaning that they don't exist as real pages. Technically speaking they are "server side scripts" and not pages, so the searcher is taken directly from the search engine listings to a script that the hijacker controls. The hijacked pages appear to the searcher as copies of the target pages, but with another web address ("URL") than the target pages.

 

Once a hijack has taken place, a malicious hijacker can redirect any visitor that clicks on the target page listing to any other page the hijacker chooses to redirect to. If this redirect is hidden from the search engine spiders, the hijack can be sustained for an indefinite period of time.

 

Possible abuses include: Make "adult" pages appear as e.g. CNN pages in the search engines, set up false bank frontends, false storefronts, etc. All the "usual suspects" that is.

 

A short description

Regarding the Search Engine Result Pages ("the SERPs"), it's not that the listed text (the "snippets") are wrong. The snippets are the right ones, and so is the page size, the headline, the SERP position, and the Google cache. The only thing that can be observed and identified as wrong in the SERPs is the URL used for the individual result.

 

This is what happens, in basic terms (see "The technical part: How it is done" for the full story). It's a multi-step process with several possible outcomes, sort of like this:

 

1. Hijacker manages to get his script listed as the official URL for another webmaster's page.

2. To Googlebot the script points to the other webmaster's page from now on.

3. Searchers will see the right results in the SERPs, but the wrong URL will be on the hijacked listing.

4. Depending on number of successful hijacks (or some other measure of "severity" only known to Google) the search engine traffic to the other webmaster dries up and disappears, because all his pages (not just the hijacked one(s)) are now "contaminated" and no longer show up for relevant searches.

5. Optional: The hijacker can choose to redirect the traffic from SERPs to other places for any other visitor than Googlebot.

6. Offended webmaster can do nothing about this as long as the redirect script(s) points Googlebot to the page(s) of the offended webmaster (and Google has the script URL(s) indexed).

 

While step five is optional, the other steps are not. Although it is optional it does indeed happen, and this is the worst case as it can direct searchers in good faith to misleading, or even dangerous pages.

 

Step five is not the only case, as hijacking (as defined by "hijacking the URL of another web page in the SERPS") is damaging in the other cases as well. Not all of them will be damaging to the searcher, and not all of them will be damaging to all webmasters, but all are part of this hijacking issue. The hijack is established in step one above, regardless of later outcome.

 

This whole chain of events can be executed either by using a 302 redirect, a meta refresh with a zero second redirect time, or by using both in combination.

 

http://clsc.net/research/google-302-page-hijack.htm

 

To Fix it,

 

add this to the <head> section

 

<meta name="robots" value="noindex">

[Roger]

Thats good info Adam. I ran across it also. ALthough not that fix.

 

I found out later that day that another user on the same server my account was on had done somenthing that allowed the server to be compromised by an intruder. The intruder had permissions such that he was able to drop the htaccess files in any world writable directory.

 

The htaccess files setup a fake 404 error which pointed to a another php file that they also dropped in as the error document. The php file then actually did the redirect.

 

Everyday is a learning experience.... :wink: Just when you think you're safe. Here they come again....

[Adam]

Everyday is a learning experience.... :wink: Just when you think you're safe. Here they come again....

 

I hear that!