From: "Hal E. Fulton" Date: 2003-07-29T01:28:58+09:00 Subject: Re: install questions ----- Original Message ----- From: "Ben Giddings" To: "ruby-talk ML" Sent: Monday, July 28, 2003 10:59 AM Subject: Re: install questions Don't want to wander too far OT... but I'm coding in Ruby after all... > Generally a CGI that requires read/write access to the filesystem has some > security concerns. Most of the time the script will run as nobody on a > UNIX-like box, but 'nobody' has to have read access to /etc/passwd and other > files. Write access is even worse because that opens up the door to all > kinds of other nasties. > > Any CGI which requires write access to the filesystem should be content with > writing to a file in /tmp, and should be ok with that file disappearing at > some point. As to writing to other directories, a program that's executable > via the web should not have the ability to write to another web-accessible > location unless absolutely necessary. Doing so makes whatever it writes > accessible by anybody else in the world. Writing to the CGI directory is > especially bad because the web server assumes that things in that directory > are exectables and so what's written could be a nasty script. > > This rule about not writing to anything but /tmp is sometimes broken by > things > which allow file uploads to a media/images directory for example, but > normally there are all kinds of precautions taken in that case. OK, I know there are some very sneaky tricks out there... most of them I would never have thought of on my own. But if my CGI chooses its own filenames and never does an eval, then how can it be a security risk even if it happens to write into (a directory under) cgi-bin? I assume the risk comes from other CGIs in that case? But regardless of where the data is stored: What about CGIs whose inherent function is recording data from the user? E.g. a guestbook? It has to write that stuff somewhere. Surely a database is overkill in many circumstances. Hal -- Hal Fulton hal9000@hypermetrics.com