Re: [MacPerl-WebCGI] replicating chmod command on a mac

[Bruce Van Allen <bva@cruzio.com>]

At 2:46 PM -0700 7/8/99, Tomer Tishgarten wrote:
>I have a cgi that is restricted to the cgi-bin folder in Webstar.
>What I recently noticed is that if someone types in our domain name,
>cgi-bin, and the cgi name, they are able to by-pass the security
>feature that I created via the cgi.  Ex:
>
>Type:
>www.domainname.edu/cgi-bin/sec.cgi
>
>Result:
>cgi processes and creates the dynamic web page.
>
>In unix, I know that you can create a read only privledge.  How do I
>replicate that feature?


There might be a server setting that deals with this, but I would go about
it differently.

(It also seems potentially dangerous to me to have one script switching the
execution permissions of another script on and off. If the first script
failed while processing for some reason, things might not be left in the
right starting positions. You'd have to add a bunch of code to run some
file checks before it tries to do anything. Too many dangers; I'm too
Perl-lazy to even want to take them on... ;-)

(Also, if you made a script read-only, then people could/would read it,
giving away all of its secrets. If execution _is_ permitted, then it will
execute when someone accesses it -- preventing them from seeing into your
code.)

I _always_ include in my CGIs some way to handle a web request directly
addressing the CGI. Visitors can always read your HTML source to find the
name and path of a <FORM ...> action CGI script, so I assume that someone
will do so. My scripts parse the action right at the start between how it
executes when addressed the way it's intended and how it executes otherwise.

What is the way you _want_ people to access your CGI? Or, more directly,
what gets someone through your security feature and on to the CGI? I would
guess that however this might happen, you're passing some arguments to the
CGI (like from a web form or appended to the URL). So near the start of
your script, check the args. If there are none, that might be the trigger
for a reject/error message. Another approach is to have a particular field
value (argument) passed along to the CGI (after the security clearance)
without which the CGI rejects the request.

Finally, you could just set it up so that directly addressing the CGI is
the way you choose to have it execute normally, including the security
steps. If a visitor can't pass the security steps, then the script rejects
them and exits. I don't always like to present links directly to CGIs, but
sometimes this is the best way to work it.

Sorry these comments are rather abstract. Without seeing some code from
you, it's hard to be more specific or suggest some code to try. My main
point here is that I assume that once a script has the necessary
permissions for execution in a web framework, those permissions are so
broad that the script has to have some other way of fending off improper
advances. So my practice is to make sure to follow good user interface
principles of gracefully handling things for users who invoke the script in
ways different from what I intended. This is a discipline that will serve
you well long after you've solved your current problem.

Hope that helps. Feel free to come back with a more detailed description of
how you wants things to work, along with code excerpts.



- Bruce

~Bruce Van Allen~
~bva@cruzio.com~

==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-webcgi-request@macperl.org