RevCGI Hosts?

[J. Landman Gay]

Dave Cragg wrote:

> I may just be nervous by nature, but I never put the engine in the 
> cgi-bin folder. By my understanding, the http server will try to execute 
> anything in the cgi-bin folder that has execute permissions set. My 
> worry is whether the server can be coerced into passing parameters when 
> it tries to run the engine. (There was a security problem in the past 
> with the Perl executable on Windows due to this.) While I'm fairly 
> confident Rev is immune from this, why take the risk?

I think we can relax as long as we don't script anything stupid. Here 
are a couple of quotes from Scott Raney about it:

> With MetaCard your primary (and probably exclusive) risk would be in
> executing commands or evaluating expressions that come from untrusted
> sources.  Any use of the "do" and "send" commands or the "value"
> function should be very diligently evaluated to make sure that there
> is no possibility of this occuring.  Of course, you also have to be
> careful about where you write files, but it's a relatively simple
> matter to check a path for validity (e.g., don't allow a leading 
> "/", or the "..", ":", or "~" characters anywhere in a path).

Which he follows with:

> I certainly wouldn't rule out building or using MetaCard server
> software, even for protocols for which well-known (if buggy) open
> source software is widely available.  While I don't see any big
> advantage to writing an FTP server in MetaCard, an HTTP server that
> executes CGI scripts is a different matter entirely and an area where
> a MetaCard server could be safer and feature-competitive with any of
> the alternatives.
> 
<snip>
> 
> I've got a soap box here too, and in *my* opinion, the ubiquity of
> buffer-overrun bugs in open source software rises to the level of
> criminal negligence.  There is just no excuse for this kind of sloppy
> programming, yet not a week goes by that yet another example of this
> kind of thing isn't found in one of the commonly used open-source
> packages.  I wouldn't blindly trust Microsoft software either, but at
> least the majority of the security holes in their products were put
> there deliberately to improve the usability of the products rather
> than as the result of poor security hygiene on the part of the
> developer.
> 
> My advice is to not be afraid of this stuff.  Sure, you have to be
> careful, but you can hardly do any worse a job than those hacks who
> are writing the software that runs the Internet ;-)

I miss that guy.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com