The browser asks the webserver to do something.

The webserver realizes that to do it it needs to run your script.

The webserver runs your script (passing it information through the CGI protocol).

Your script sends the webserver text.

The webserver returns that text to the browser.

The browser does not know the CGI script is there. While the CGI script may guess there is a browser there, it doesn't really know that, it only knows about the webserver. And the operating system only knows how to help the webserver chatter to the outside world, and that the webserver can run your script.

So the short answer. The browser can do whatever the webserver is willing to do on its behalf, and as long as the webserver can run your script, that includes running your script. Conversely if you don't want the browser to do something (like run the Perl interpreter directly) you need to take that up with the webserver. (Which is why it is a really bad idea to put perl in your cgi-bin.)

I've been known to put the following code in a script in an attempt to guarantee it not be run from a browser.


localonly();
...
...
...

sub localonly {
   if ($ENV{'SCRIPT_FILENAME'}) {
      die "localonly -- $ENV{'REMOTE_ADDR'}";
   }
}
[download]

This seems to work.
But, I'd be curious if there's any feedback on exploits which can get around the SCRIPT_FILENAME or perhaps a better way to do this.

Claude

OK. It's just that I've seen scripts that refuse to run unless they have user, group, and other exectuables checked. This is what is confusing me. I'll keep banging away at this and get it figured out somehow.