views:

48

answers:

2

Opinions: I want to disallow direct invocation of certain scripts, that have functionality accessible from a menu, via Web at the OS level (linux).

I was hoping to call a authorize.pl script that checks the session validity, checks user privileges etc. Then it will redirect to the target script.

Does this get around permissions? Could I restrict execute on the target scripts from public, but set target scripts accessible to group to which authorize.pl belongs? Does this reflect any current practice?

A: 

If you plan to redirect to the target scripts the group authorize.pl belongs to is irrelevant, the scripts have to be executable by the webserver user.

Why do you want to do this at OS level? Using plain old session-based authorization where the check is done in each script is the standard practice.

Instead of calling authorize.pl and redirecting to target, create a module called Authorization.pm and use it in each script, calling a validation function first thing. This function would redirect to a login page (or take another appropriate action) if the proper credentials are not present.

Something along the lines of

use Authorize qw{validate}; #Your module
use CGI::Session;
use strict;
use warnings;

my $sess = new CGI::Session();
validate($sess->param('user_token'));

#Unreachable code if session is empty or invalid

#Rest of the code ...
Vinko Vrsalovic
(1) We could compile the authorize script for speed, (2) we could wholesale block requests of scripts with database function to increase security. But I see: when the location is printed to the user by authorize the browser requests the target script.
A: 

We were thinking (1) we could precompile the authorize script for speed, (2) we could wholesale block requests of scripts with database function to increase security. But I see what your saying, permissions have to be set to User Execute for the script to communicate with the client: when the location redirect is printed to the user by authorize the client browser requests the target script.

This whole approach smells like premature optimization, both performance and security wise. You can call database functions from the origin script, you can also use webserver's security to block ranges of IP addresses or other criteria (Apache mod_security's worth looking at) and so on
Vinko Vrsalovic