Blockin inbound "meta-refresh links" from hostile website

Forum Moderators: coopster

Message Too Old, No Replies

Blockin inbound "meta-refresh links" from hostile website

I'm being linked to through meta-refreshes. How to stop this nonsense?

helleborine

5:28 pm on Oct 12, 2010 (gmt 0)

I'm not sure if some server side scripting could help me with this problem.

I'm being linked to through a referrer-spoof with a double-meta refresh, and I need to stop this from happening.

I'd very much appreciate at least a hint of where to turn. I'm willing to hire someone to do this for me, but alas I don't even know WHERE to ask... because I haven't a clue as to what techniques may be employed for this. PHP? perl? htaccess? Something else?

Thanks ahead.

Anyango

7:47 pm on Oct 12, 2010 (gmt 0)

Which language is your site's code in ? PHP ? ASP ? etc.

And also if you know which site is doing that you can blacklist its ip address on your server even if the referer is spoofed

helleborine

8:27 pm on Oct 12, 2010 (gmt 0)

Right now it's in html.

But I cannot blacklist IP addresses as the referrer spoofed double meta refresh links are used by real people.

enigma1

9:33 am on Oct 13, 2010 (gmt 0)

The short answer is you cannot stop it from happening because you do not control the referer field of the client. And a DMR or equivalent method may clear the referrer subject to how the browser is handling each case.

Even if browsers start handling the referrer differently an external server can still setup the response header he wants so the browser will not setup or clear the referrer field.

helleborine

12:13 pm on Oct 13, 2010 (gmt 0)

And an incoming meta-refresh is not detectable in any way?

I'm kinda surprised because some browser add-ons do block them.

enigma1

12:51 pm on Oct 13, 2010 (gmt 0)

The browser can detect various things the server sends over. But is not your server that does that. Is an external server who sends the html for the meta refresh. And the client (browser) is controlled by the visitor. In other words you cannot get in-between client/external-server from your own server.

It's not possible because you would have to ask each visitor to install a plugin or configure his browser in a certain way.

rocknbil

4:09 pm on Oct 13, 2010 (gmt 0)

Do you have a consistent $ENV{'HTTP_REFERER'} for these incoming visits? If you do, you can at least deny it by referrer with a 401 via mod_rewrite.

helleborine

4:11 pm on Oct 13, 2010 (gmt 0)

I am not familiar with $ENV{'HTTP_REFERER'}.

These visits are referred by "-"

Dijkgraaf

1:43 am on Oct 14, 2010 (gmt 0)

Are they serving your page up in an IFRAME?
If so look at using the X-Frame-Options HTTP header tag.

helleborine

2:06 am on Oct 14, 2010 (gmt 0)

It's in this format:

<html>
<head>
<title>EDITED OUT</title>
<meta�http-equiv="content-type"�content="text/html;�charset=utf-8"�/>
<meta�http-equiv="refresh"�content="
1
0
6
;�URL=
3c
http://mywebsite.com/4mywebpage.html
103
">
<meta�name="keywords"�content="anonym,anonymous�link,link�anonymous,�short�refer�link,�anonymous�redirector,�hide�referer">
<meta�name="description"�content="Hide�referring�urls�from�the�public,�and�shorten�link�anonymous">
</head>
<body>
</body>
</html>

rainborick

2:59 pm on Oct 14, 2010 (gmt 0)

An HTTP_REFERER value of '-' means it was a direct request. You could certainly block such requests at the server level, but it would mean you would also be blocking type-in traffic and traffic from user bookmarks. I could see where you could possibly afford this on an internal page, but if it's your site's main page, it would be a terrible idea.

The only solution I can think of would be to add some JavaScript to your page that would detect the value of 'window.parent' to see if it's null or not your domain, and then deal with it from there. Search for frame-buster scripts and that should give you some ideas.

helleborine

9:27 pm on Oct 14, 2010 (gmt 0)

Actually, I don't mind cutting off access to my internal pages, and leaving the INDEX page accessible.

How is this done?

Also, is there some ready-made javasctipt somewhere that does the job of detecting the value of 'window.parent' that I could use?

If there is none ready made, I might have to hire someone.

jimbeetle

9:57 pm on Oct 14, 2010 (gmt 0)

I usually can't find much using Google any more, but a quick search of a few of the keywords shows that it's probably a hiderefer dot com link.

It's an anonymous redirector to mask referrers. A site uses a link constructed something like this for it's external links...

http ://www.hiderefer.com/?http ://www.example.com/page-one

...and they're funneled through a no-referrer proxy.

I'm not devious enough to come up with a reason for it, though I'm sure there are those around who can.

helleborine

10:20 pm on Oct 14, 2010 (gmt 0)

The internet is a war zone.

I'm getting these links from a competitor.

There are several of these referrer spoofs, hiderefer being one of them (though another is being used on me, I'm sure it works in a similar way).

Unfortunately for me, the no-referrer proxy doesn't override the visitor's IP, so I can't block by IP.

enigma1

1:32 pm on Oct 15, 2010 (gmt 0)

When you say you get those links what you mean? These are accesses on your server but if these are potentials clients why you are trying to block based on the referrer? There are also other who surf the net with the referer field blocked on purpose including me.

The bad thing will if you ban IPs based on that because if your competitors figure it out they will force potential clients to trigger your traps.

helleborine

6:47 pm on Oct 15, 2010 (gmt 0)

It's a loooo-o-o-o-o-ng story.

In part I want to discourage the use of the double-meta-refresh links, I'm not sure how Google interprets such links.

Also, the sort of plagiarism that can't be taken care of through DCMA.

I'm looking for a technical solution.