I was suffering from hundreds of people using scripts on my server, so I've started searching around for a free script protector, which would read authorised domains from a text file. I couldn't find any, so I found myself learning a little Perl. This is my first script, so please don't laugh if you see silly mistakes and needlessly long code.. Need your ideas and help to make it better.

The script needs a text file with authorised domains in it, one per line.. And the log file.. I could not find out how to create the log file if it does not exist. The code should do, but I guess it's a good old permissions problem. Here it comes, will be waiting for your comments..
#!/usr/bin/perl # SECURE DOMAIN SCRIPT PROTECTOR # # This script protects any Perl script against unauthorised use. # Put it before the script but after the line "#!/usr/bin/perl". # Script reads "authoriseddomains.txt" file which includes authorised # domains, one domain per line. If calling URL does not match any # of the domains listed, gives an error and logs an error message. # # Created 30/09/2001 Last Modified 06/10/2001 # Created by : Mustafa Odabasi - modabasi@virgo.com.tr # Version 1.0.1b ###################################################################### +###### # DEFINING DATE VARIABLE chop ($date = `/usr/bin/date`); # OPENING AUTHENTICATION FILE open(DOM,"authoriseddomains.txt") or die ("Can't open authoriseddomain +s.txt: $!"); # CONTROL PROSEDURE while (<DOM>){ chomp; if ("$ENV{'HTTP_REFERER'}" =~ /$_/i){ $sonuc = 1; { } } if (eof(DOM)) { if ($sonuc != 1) { # LOGGING UNAUTHORISED ACCESS open(LOG,">> /var/log/scriptprotector.log") or die ("Can't open script +protector.log: $!"); print LOG "$date Calling URL: $ENV{'HTTP_REFERER'} Client: $ENV{'REMOTE_ADDR'} -----------------------------------------------\n"; close(LOG); # SHOW AN ERROR MESSAGE TO THE CLIENT print "Content-type: text/html\n\n"; print "<html><head><title>AUTHORISATION FAILED</title></head> <body bgcolor=white> <br><center><b><font face=\"Arial\" color=red size=\"3\">AUTHORISATION + FAILED</font> <br><br><font face=\"Arial\" color=blue size=\"3\">$ENV{'HTTP_REFERER' +}</font> <br><br><font face=\"Arial\" color=red size=\"3\">is not authorised to + use this script. <br><br>Remote address </font><font face=\"Arial\" color=blue size=\"3 +\">$ENV{'REMOTE_ADDR'}</font> <font face=\"Arial\" color=red size=\"3 +\">logged. <br><br>$ENV{'SERVER_SIGNATURE'} </b></font></center> </body></html>"; exit; } } } close(DOM); ###################################################################### +###### # PROTECTION CODES END HERE, YOUR EXISTING SCRIPT CONTINUES AFTER THIS + POINT ###################################################################### +######


Mustafa Odabasi
modabasi@virgo.com.tr

Replies are listed 'Best First'.
Re: Script protector from a 'very' newbie.. (boo)
by boo_radley (Parson) on Oct 06, 2001 at 08:38 UTC
    Chances are you are duplicating some functionality of your web server in this effort. Typically this is configured as a deny/ allow statement. For Apache, see here. I don't know what the equivalent is for IIS.
    I think the only thing that would justify this is the possibility that you don't control the webserver, but can run CGI scripts. You should still know that the envrionment variables can be faked through assorted means, and could still allow unwanted access.
    Also, as my celebratory "use CGI" week wraps up, I'd like to suggest that you use cgi.pm both for the HTML and for accessing the env. vars.
Re: Script protector from a 'very' newbie..
by jj808 (Hermit) on Oct 06, 2001 at 12:33 UTC
    Have a look at http://www.datatrendsoftware.com/spoof.html. As you can see, it's quite easy to fake the HTTP_REFERER variable. You should also be aware that HTTP_REFERER will not be set if someone types in the URL of your script - it will only exist if they've followed a link. Some browsers do not even send this information anyway. Therefore I think you should modify your script to allow access if HTTP_REFERER is undefined.

    Sorry for being a bit negative, but by using this system you do stand a good chance of blocking authorised access while not really offering much protection against unauthorised people using your scripts.

    JJ

Re: Script protector from a 'very' newbie..
by Chady (Priest) on Oct 06, 2001 at 14:21 UTC

    If we want to discuss ur coding style, I can see a few things I'd like to point out:

    when you open the file, it's good that you are checking for success, but since you're using or and not || you can drop the parens, and consider NOT hardcoding the filename in the statement:

    $domainsfile = 'authoriseddomains.txt'; open DOM, $domainsfile or die "Can't open authoriseddomains.txt: $!\n" +;

    proper indentation of your code will help you track bugs; if you do this, you will find an un-nessecary empty code block inside the first if

    Then there's the error message, you are using this in a CGI script, so a great chance you are calling CGI.pm, so why not use it to print out the HTML nicely?

    and one more thing about structure; if you move the error checking if ($sonuc != 1) code block after you close DOM you wouldn't need to run through it in every iteration.

    just my 2 cents worth of blabering.


    He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

    Chady | http://chady.net/