At 01:48 PM 9/6/2001 -0700, Curtis Poe wrote:
>--- randy Peterman <[EMAIL PROTECTED]> wrote:
> > >I have to ask: where are you getting the $UserName value? What you are
> > trying to do raises some
> > >serious security issues if done incorrectly.
> >
> > I am getting it from a form input.
>
>Randy,
>
>The problem with that is untainting an email address (see "perldoc
>perlsec") is *very* difficult
>to do correctly. Let's say that the input box is named "UserName". If
>you make any mistakes
It is not so bad to do if you just filter on the basic characters you want
and leave out shell metas. I have a sample regex in my taintmode FAQ
(http://www.extropia.com/tutorials/taintmode.html), but as others have
pointed out, it doesn't allow the entire correct universe of email
addresses to go through precisely because shell meta characters ARE valid
in email addresses. However, I consider this situation quite rare.
Note that a TRUE regex to filter whether an email address is valid is HUGE
and takes up well over a page of text in O'Reilly's book on Regular
Expressions by Jeffrey Friedl (sp?). But I would consider this overkill in
most situations.
>validating that information, you can open up your script to a HUGE
>security hole by allowing user
>data near the shell. Consider the following URL:
>
>
>http://www.somehost.com/cgi-bin/mail.cgi?[EMAIL PROTECTED]'%3brm%20-fr%20*%3b
>
>Your shell command then becomes:
>
> /usr/lib/sendmail -t -i -f'[EMAIL PROTECTED]';rm -fr *;
>
>Admittedly, I'm not a Unix security expert, but I suspect that this will
>have undesirable effects
>:) Playing around with that for a while should allow the cracker to have
>all sorts of fun.
Yes it would. However, I do believe sendmail is a perfectly acceptable way
of sending mail, but it should be done properly. I have rarely seen the
need to send email addresses on the command-line with sendmail. Randy
should be able to just do something like
IPC::Open3::open3(*OUT, *IN, *ERR, "$path -t");
my $mail = qq[To: $to
From: $from
Replyto: $replyto
Cc: $cc
Bcc: $bcc
Subject: $subject
$body
];
print OUT $mail;
close (OUT);
close (IN);
close (ERR);
Where $path is the path to sendmail. This makes sure you send all your
addresses through the STDIN stream rather than the command-line. The STDIN
stream is not interpreted by the shell so there is no problem.
Note that I like to use IPC::Open3 which is fairly cross platform (even on
Windows Perl -- although sendmail doesn't exist there) and allows you to
capture the errors and output from sendmail if you want to debug why
sendmail isn't working. Otherwise just opening with a open() plus the pipe
symbol only lets you send input into the program but doesn't easily allow
you to read the output without resorting to nasty temp files.
[Sendmail As A Valid Choice To Send Mail]
To me, the disadvantage of sendmail is that it launches an extra process.
But there are two pros which make command-line sendmail quite useful to a
CGI programmer.
1) As a CGI developer, I can be pretty certain that 90% of the ISP servers
I install my CGI script on will just magically "work", because the sendmail
binary (including pseudo binaries that come with alternate servers like
qmail) will automagically KNOW the right SMTP server IP address etc.
without having to do ANY script configuration.
This is a huge win in maintenance.
2) When you give Net::SMTP an SMTP address that is currently down what do
you do? Just error out your application? Generally emails are not mission
critical but are rather notifications which can be selectively delayed.
If you send mail using the sendmail binary, even if the SMTP server it
connects to is down, the sendmail binary can keep the message in a queue
and keep retrying to send it long after your CGI script has delivered its
HTML response payload back to the client.
> > I am hard coding the "to" line so that I
> > do not have to worry about spammers just using my page as a portal. Also
> > they are registered users with cookies and passwords to authenticate things
> > so that there should be very little chance that anything should be relayed
> > by accident.
>
>Cookies and passwords are very easy to sniff, social engineer,
>etc. You're using SSL to afford
>minimal protection, yes?
>
> > then the list is checked to see if the person can post or not
> > (its a private list)
>
>Good! Then you should already have their email address. Rather than
>accepting $UserName from the
>form input, validate the user and, if valid, grab their email from your
>internal data (which
>hopefully is secure) and use *that* email.
I wholeheartedly agree with this assessment. Definitely the best solution
is to hard-code the $to address inside of a configuration variable as
opposed to allowing it to change based on form input.
Later,
Gunther
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
