Thread: Preventing Hotlinking of CGIProxy

I run a small CGI Proxy Site.

I haven't devoted a lot of effort yet to digging into CGIProxy, but I had to do so earlier today because of a problem with a hotlinker.

A fellow named Song Guo Qiang runs a site called Mamproxy that does nothing but hotlink CGI Proxy sites.

I added the following code to the virtual host entry for this domain in httpd.conf. This should prevent the hotlinking and redirect visitors back to the domains home page.

Code:

    # Prevent hotlinking
    RewriteCond %{HTTP_REFERER} !^http://(www\.)?cgiproxysite.com(/)?.*$ [NC]
    RewriteRule ^/cgi-bin/nhp-cgi-proxy-site.cgi(.*) http://www.cgiproxysite.com [R,NC]

Looks like you did the trick, when I tried (you were no 9 on his list btw) it redirected me right back to your domain!

Good, now hotlinking not working, just checked

The problem Will is if they have referrers disabled they will slip right threw!


An added security would be to use both Session/cookie and referrer checking.

How this works is first you check if they have a Cookie that says "yes I visited the homepage!' When they enter the proxy pages. (Which you set when they visit the home page) . If they don't, then check the referrer. If the referrer is blank or wrong then redirect them to the homepage. This still allows users to have cookies disabled in their browser as long as they have referrers enabled. (or vice versa, but not both)

Cons: In the rare case you may lose a visitor if they have Cookies and referrers disabled and refuse to enable one of them. But the need for security I believe outweighs those rare visitors.

3rd level of security is too use URLs that expire by appending and requiring a random salt on the URLs that will expire after a day, hour, whatever. At this point any hotlinking should be thwarted. It just would be too impossible to successfully hotlink anything.

Of course that is just the logic of it. Its unfortunate that Cgiproxy (And also PHProxy) were not made with hotlinking protection in mind.

Do you know where to find code to implement a cookie system such as the one you are describing?

Originally Posted by Will.Spencer

Do you know where to find code to implement a cookie system such as the one you are describing?

In perl I dont sorry.

In PHP however its

PHP Code:

setcookie($_COOKIE['no_hotlink']); 


or PHP session.

PHP Code:

 $_SESSION['no_hotlink']; 


This is the logic in PHP of what I described in the my other post above. (As taken from Glype 1.1).
At some point higher in the script at session is started on the index. So they should have the session started when they visit the homepage before
they enter the proxy pages. However now that I think of it Glype is broken up into several files with the code below belonging to the browse.php file while Cgiproxy is 1 file. So it may create conflicts such as having a infinite redirect loop cuased by the script requring a cookie while its still not determined to be set. (which I learned a hard lesson about just recently lol) if you happen to start messing about with it you find out or not if can be done.. But yes here the logic of it.


(The logic of this would have to converted to Perl compatible code)

PHP Code:

/*****************************************************************
* Protect us from hotlinking
******************************************************************/

// Only Invoked if they did NOT provide a Cookie/Session
if ( empty($_SESSION['no_hotlink']) ) {

   // Assume hotlinking to start with, then check against allowed domains
   $tmp = true;

   // Ensure we have valid referrer information to check
   if ( ! empty($_SERVER['HTTP_REFERER']) && strpos($_SERVER['HTTP_REFERER'], 'http') === 0 ) {
      
      // Examine all the allowed domains (including our current domain)
      foreach ( array_merge( (array) GLYPE_URL, $CONFIG['hotlink_domains'] ) as $domain ) {

         // Do a case-insensitive comparison
         if ( stripos($_SERVER['HTTP_REFERER'], $domain) !== false ) {
            
            // This referrer is OK
            $tmp = false;
            break;
            
         }
      
      }

   }
   
   // Redirect to index if this is still identified as hotlinking
   if ( $tmp ) {
      error('no_hotlink');
   }

}

// If we're still here, the referrer must be OK so set the session for next time
$_SESSION['no_hotlink'] = true; 


I thought about it for a moment. For it too work you would have to place a Setcookie in the area function of the script thats only invoked generating the homepage. the anti-hotlink code would have to placed somewhere in the function thats only involved and invoked with dealing with grabbing the content or sending it to the user. This would effectively seperate the two functions from collsions and cuasing conflicts. Else you would have the antilink function running on the homepage before they even get a chance of getting a cookie to send. (Thus the infinte redirect loop). I hope you understand. Perl is not my area of expertise I do have a little bit knowledge of cgiproxy source. It may take ALOT of tinkering of cgiproxy to get it right and bit of reading on perl for you. Have fun.

Originally Posted by dollar

I thought about it for a moment. For it too work you would have to place a Setcookie in the area function of the script thats only invoked generating the homepage. the anti-hotlink code would have to placed somewhere in the function thats only involved and invoked with dealing with grabbing the content or sending it to the user. This would effectively seperate the two functions from collsions and cuasing conflicts. Else you would have the antilink function running on the homepage before they even get a chance of getting a cookie to send. (Thus the infinte redirect loop). I hope you understand. Perl is not my area of expertise I do have a little bit knowledge of cgiproxy source. It may take ALOT of tinkering of cgiproxy to get it right and bit of reading on perl for you. Have fun.

Actually, the solution you proposed is exactly in what Glype and other scripts base their anti-hotlinking solutions.

An alternate solution (since no one appears to know Perl) would be to create a PHP file that would be called into a <script> tag which would check for the cookie to exist. Else, break out of frames (if any) and redirect to homepage, where another script would be called which add the cookie or start the session.

Will, can you add a custom code to the footer or the header of the proxified pages and modify the appearance of the homepage at the CGI proxy? If you can, this is doable.

Please note, this code has not yet been tested! I wrote it here as-is!
It might fail, so if you're not a PHP developer please do not use this code!

Code for antileech.php:

PHP Code:

<?
error_reporting(0);
session_start();

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); // always modified
header("Cache-Control: no-store, no-cache, must-revalidate"); // HTTP/1.1
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache"); // HTTP/1.0

if ($_GET['install']){
  $_SESSION['secret3'] = 'ok';
  exit;
}

if ($_SESSION['secret3'] !== "ok"){
  echo 'top.location="/";';
}

?>

Code to add to homepage:

HTML Code:

<script src="/antileech.php?install=true"></script>

Code to add to proxified pages' header:

HTML Code:

<script src="/antileech.php"></script>