RE: Secure Form Script?
From: Glynn Clements (glynn.clements_at_virgin.net)
Date: Wed, 19 May 2004 23:28:24 +0100 To: Beth Skwarecki <email@example.com>
Beth Skwarecki wrote:
> 2) HOWEVER, it's silly to be using sendmail at all, in most cases. This
> is what the perl module Mail::Sendmail is for. You give it a hash with
> all the headers you want to send, and it sends directly (it is *not* a
> wrapper around the sendmail binary; it works on all platforms, even
> when sendmail is not installed):
There isn't any mechanism for sending mail which will work on *all*
platforms. Although executing "sendmail" and feeding it the message on
stdin is likely to work for almost any Unix system which is actually
capable of sending mail.
Looking at that, I see:
Simple platform independent e-mail from your perl script. Only
requires Perl 5 and a network connection.
The "requires ... a network connection" part might actually be a
genuine obstacle. It's a safe bet that a network connection that goes
no further than the firewall isn't likely to suffice.
No suport for the SMTP AUTH extension.
Again, this could be a genuine obstacle in many situations. It's quite
common for direct outbound connections to be blocked (even from a web
server), requiring the use of a specific proxy (e.g. for content
filtering) which may well require the use of SMTP AUTH.
This is, in large measure, why simply feeding the message to
/usr/lib/sendmail (or /usr/sbin/sendmail on some Linux systems) is
often the most reliable option. Whatever specific requirements a site
may have, if a sendmail binary (or script) exists, it's likely to be
configured so as to meet them.
Whilst a direct SMTP connection may be viable in many situations,
there are others where it isn't. There are situations where it is
necessary to invoke sendmail (although the issues would seem to apply
equally to any similar program), and so the question of how to do so
safely is a valid one.
Another of the limitations listed for Mail::Sendmail is:
Headers are not encoded, even if they have accented characters.
This suggests (I haven't examined the code) that the supplied strings
*may* be dumped verbatim into the message. If that is the case, and
you are using user-supplied values from an HTML form, be sure to
sanitise them first. Otherwise, this could make it trivial for an
attacker to generate malicious messages. If they can include CR/LF
characters, they may be able to generate additional headers, as well
as moving any subsequent headers into the message body.
> CPAN is your friend. :)
If I was a black-hat, I might agree with that statement;)
As I said, I haven't examined the code. But then I'm not actually
using it to allow anyone to send email from my webserver. Anyone who
is planning on using it should definitely examine the code.
-- Glynn Clements <firstname.lastname@example.org>