Help with basic CGI project?

[J. Landman Gay]

Sadhunathan Nadesan wrote:

> What if you want to create a file that is more permanent in nature,
> that can be overwritten by a CGI, and that can be accessed by anyone?
> 
> Will this raise cries of security hole, red flag, dangerous no-no?
> 
> Solution?:
> 
> Is there a security guide to creating such a directory/full path to file
> "place"  such that it's ok for a CGI to write there, to keep the files
> around permanently, and for an arbitrary user (who has log in permission
> or file share permission, such as via SAMBA), to have access?

I think you can place the file wherever you like. The engine is secure 
when used as a cgi, provided your scripts don't do anything to breach 
that security. Here is a repost of a similar question and the reply from 
Scott Raney, back when the engine was still MetaCard:

A user wrote:
>> in any case MC hasnt been rigorously analysed for buffer-overrun
>> attacks afaik.  Not only should you be cautious about using it for
>> sensitive data, but also on any virtual file system with sensative
>> or mission critical data, unless you are very sure that the
>> permissions DONT allow it to write to disk, or read sensative
>> data. still the active copy *in ram* may be rewritten, and you dont
>> want to run MC out of inetd!
> 
> Certainly paranoia is warranted here, but you should keep in mind that
> the average cobbled-together MetaCard server is going to be safer, at
> least WRT to buffer-overrun security problems (the easiest to exploit
> and most dangerous kind), than virtually any current open-source
> server program.  This is obviously the case when compared with the
> FTP, HTTP, and BIND servers that are running on the majority of
> Internet hosts out there, all of which have multiple security holes
> like this, one of the buffer-overrun bugs in BIND (the DNS server)
> being the single most commonly exploited security hole in any server
> software.
> 
>> any door can be broken, with a lever long, and strong enough, but
>> dont leave the door open.
> 
> 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).
> 
>> MC was built (in the image of HC) to make GUIs and be an OO database
>> with advanced scripting capabilities, it now includes inet_socket
>> functionality. do not assume that just because you can, you
>> should. There are tried and true methods of sharing files
>> SCP2,FTP,HTTP don't reinvent the wheel unnessesarily.  write
>> software to co-ordinate these underlying transactions to provide a
>> nice GUI to people who need to access data without learning how
>> technology works.  keeps development time down, and reduces the
>> complexity of your product, while reasuring the customers (end
>> users) of compatability.
> 
> 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.
> 
>> yes i am the first to admit i am rather opinionated on some of the
>> issues here, that dosnt make me right/wrong.
> 
> 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 ;-)






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