[EMAIL PROTECTED] wrote:
>>>>> "bobmin" == bobmin <[EMAIL PROTECTED]> writes:
> bobmin> So what I need to do is
> bobmin> somehow fix this lockout routine so that this bogus website
> bobmin> cannot remotely execute our script.
Does the bogus webserver call your CGI-Script (and serve as a sort of
proxy)? Or do they have static links to your script on their stolen
pages, so that their vistors call your script directly?
I asume the second case.
> bobmin> Its got to be something
> bobmin> that they cannot lift from the html code. Is there some
> bobmin> variable in the environment that is ALWAYS returned that I can
> bobmin> test for? I don't want to lock out the people who's system
> bobmin> doesn't provide a referer just because of one bad apple.
> Even if you did lock out all non-referers, it's trivial to write a
> script to provide the proper referer. I've done it a few times,
> even in one of my columns, so the word is out there.
>
> Referer is just a hint. Log it for approximate data, but NEVER NEVER
> NEVER use it for authentication or authorization, as you have
> discovered.
> It can be absent, wrong, or just plain forged trivially.
I fully agree with the last sentence.
However, depending on the desired "security level" a CGI-script that locks
out requests with the wrong referer (but accepts requests without referer)
may be the best solution.
It will not lock out all "fraudent" requests and it is easy for the
client to forge it. But most clients send correct referers by default.
And third party vistors have no reason to manipulate the referers when
they call your script for the first time.
I don't know any way for the fraudent webserver to manipulate third
party clients, so that they ommit the referers (or send forged
referers) when they request your script.
Thus, I expect that the simple referer check will inform >90% of
the visitors that come from the fraudent webserver about the theft.
There are other authorization or authentication schemes that
provide a higher "security level". But IMHO they would cause a severe
overhead and may restrict the "rightful" use of your script.
> You can block an IP range or domain name from any access to your site
> using the webserver's restrictions. Go read. :)
That would be the best solution, if the fraudend webserver acts as
"proxy".
Ciao, Claus [EMAIL PROTECTED]
--
Sent through GMX FreeMail - http://www.gmx.net
