[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

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



Hi Bruce,

Thanks for the comments.  Actually, they were very helpful in 
attacking my problem.  As suggested, I've decided that I would need 
to first add a way for the script to execute when directly accessed. 
This would be an initial way to eliminating any hackers that can read 
the HTML source on the path.  I run a site at an education 
institution, so I dont expect much trouble, but I always believe that 
you must protect yourself.

If necessary, I'll probably be back to ask more questions.

Thanks again,
Tomer


>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


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