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