Ok. I'm prepared for major downvotes for even doubting the Monks on this. But it is popular opinion here that Matt's Script Archive (MSA) is "insecure". To me "insecure" means that using this script will cause your web server to become vulnerable to attack of the type which allows access by unauthorized individuals. This is a separate and distinct failing in a script from the lesser affliction "easily broken"-- which simply means that the script can be caused to fail due to programming errors that failed to account for some input.

The code below is, I think, the most recent MSA and even I can see that it is easily broken. But is it insecure? If it is insecure, why is it that there isn't a Code RedHat worm crawling the web looking for pages with forms that submit to a script called MSA is extremely common, after all.

I will point out some obvious flaws, and artifacts to get the discussion going, but none of these are server-endangering in any capacity that I'm aware of. If they are, the Perl Monks community has an opportunity to make sure that we review and publicize the existence of a secure alternative (perhaps btrott's STAMP), and get it on CPAN. If nothing else, the replies to this post of mine will serve as further information for the curious.

The flaws that I notice:

  • Does not use CGI. This means that form input has to be hand-parsed. Is this potentially insecure, or is it just trivial to break, resulting in a 500 error or no action for the user?
  • Relies on system calls to sendmail. It does have the path hardcoded in full for this, and could conceivably point to any MTA. Is this a concern given the next point?
  • Does not use Taint mode. We all know that taint will prevent accidentally letting the user send unchecked information to the system. It is not a magic bullet, since in using it we still have to decide what to allow, and the strength of our script depends on what we allow.
  • Does not use -w or strict. These are great for development. But if it could compile under -w and strict, and produce no warnings or halts, then it is safe to take them out right? Note: does not compile under strict. Under -w it only emits one warning. added: as chipmunk points out, these have runtime effects as well, so taking them out in production will not catch certain runtime errors that are part of the benefits of the -w and strict. Once they're there I see no reason to take them out again and wouldn't recommend it, unless you have some BOFH who just won't stand for detailed and descriptive error logs.
  • Script retains artifacts of the code that made it insecure in the past-- interesting but not useful code that isn't breaking the script, but isn't actually improving its quality. See $ENV{'HTTP_REFERER'}. This used to provide an open relay since it is trivially spoofed, but the newer script also checks for valid recipients, and those cannot be spoofed, since the valid domains for recipients have to be hard-coded into
In the script's defense, it looks to have been written in a Perl 4 style (at a time when this would have been appropriate). Matt may not be interesting in changing the ability to run this on a Perl 4 machine (does it, in fact, still run on a Perl 4 machine?). While Matt may be overly concerned with backwards compatibility, is his method of staying compatible a security risk?

UPDATE: I have removed the code from Matt's Script Archive and replaced it with this link to After reading the copyright statement, I felt I was possibly engaging in distribution of the script-- an activity I did not obtain permission to engage in.