Since this is a shared IIS server, I wouldn't consider data in RAM safe. At the very least, how do you ensure physical security of the server, console access, remote logon? Okay, this is a problem faced a lot though, and generally accepted practices prevail.
Supposing ActiveState Perl is installed, there are 2 ways Perl CGI can be run: in-process and out-of-process. Perl for ISAPI handles CGI's in-process and perl.exe handles them out-of-process.
Perl for ISAPI's perldoc says:
The main advantage of PerlIS over perl.exe is that PerlIS runs as a DLL in the web server's process space. Because Win32 platforms set up a protected memory space for each process that is started, there's a lot of overhead in starting a new process or program. Passing scripts to an interpreter, such as perl.exe, requires starting a new process for every script, which gets expensive in terms of system resources.DLLs, on the other hand, don't need their own process space; they use the space of the process that calls them. They don't require nearly as much overhead to start, and once loaded they stay loaded until the calling process ends. PerlIS therefore runs Perl scripts with a quicker turn-around time than perl.exe.
Draw your own conclusions (from extensive testing).
There is also the possibility of a trojan perl.exe being installed on the server... how can you verify it? Or a trojan cgi script (if the ftp password is snagged--or file permissions are weak--or the shared admins are criminal). Yuk.
I would be paranoid... but I usually am. YMMV.
--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
In reply to Re^4: Is data in RAM insecure, or am I just paranoid?
by Solo
in thread Is data in RAM insecure, or am I just paranoid?
by theAcolyte
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |