Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: CGI recipient Option

by iburrell (Chaplain)
on Sep 01, 2004 at 16:29 UTC ( [id://387593] : note . print w/replies, xml ) Need Help??


in reply to CGI recipient Option

There are two ways to specify recipients with sendmail. Either pass them on the command line, or use the '-t' option and it will pull them out of the To:, Cc:, Bcc: headers. Since you want to have the recipients in the To: header anyway and it is safer to put them in the header, use '-t' option.

Now, the To: header separates the list of recipients with commas. One way is to concat onto the recipient string.

$recipient .= ', somebody@somewhere' if $FORM{'ckusno'};
Another way is to have a list of recipients and join them together.
push @recipients, 'somebody@somewhere' if $FORM{'ckusno'}; my $recipients = join(', ', @recipients);

However, you should not put this script up on the web. It will be hacked. It will be used to send spam through your server. It will get you and your employer is lots of trouble. It may allow the server to be compromised and taken over. That might not be a bad thing because the hackers might delete this script.

Replies are listed 'Best First'.
Re^2: CGI recipient Option
by quissett (Initiate) on Sep 01, 2004 at 16:52 UTC
    This script is only used internally by a small office. I am not too concerned about the security. However, are there some steps I can take to make this script more secure? Thanks for your info!!!!!!!!!
      The import question is it accessible to the web? Being used internally may make it harder for bad guys to find and exploit. But as long as it is visible to the whole web, it is vulnerable.

      First, use CGI.pm to parse the form parameters. There are bugs and security issues in parsing form parameters that CGI.pm fixes. Lincoln Stein has done the work, and tons of people have tested and trusted it, so you don't need to. If you want a hash, use Vars method.

      Second, reduce what comes from form parameters. Form parameters can be set to anything by attackers. For example, with the Reply-to line, I could send "your@email-address\nTo: some spam viction\nSubject: this is spam\n\nMy spam message" as the espr2 parameter. The recipient receives some spam with your message as junk at the end. Hard code them in the script where you can. You have done with with the recipient which is good. One trick is to reorder the headers with form parameter fields last.

      Some values, like the From: line in your script, have to come from the form parameters. Validate those that are important from a security stand point. Email address parameters should only look like an email address, and you can be more strict than the general address matching. Names in headers should just be words. Other fields in the header should not contain line breaks.

        I understand where you are coming from. I actually inherited these scripts and have been trying to improve on them. Anyway, does it matter that the Reply-to fields are acually hardcoded into the forms? These are checkboxes with the fields hardcoded. It is not a big deal to change these to have the script run them. Just thought I would ask. Thanks for your help. I really do appreciate it. q