Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^3: CGI recipient Option

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


in reply to Re^2: CGI recipient Option
in thread CGI recipient Option

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.

Replies are listed 'Best First'.
Re^4: CGI recipient Option
by quissett (Initiate) on Sep 01, 2004 at 20:06 UTC
    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
      Unfornately, hardcoded values in the form are just as insecure as regular form values. There are two ways to attack a script. One is to put values in the form; hidden fields are safe from this. The other is to construct a fake POST after looking at the form. This is easy to do, and any value can be passed for any form field.

      If you can, hardcoding the values in the script or a config file is much safer. You might not be able to if the values depend on which page is doing the calling, or is coming from a select box.

      With fixed form fields, your validation job is easier. You know exactly what values are present in the page and what their format is. You don't need to accept input from people who will enter all kinds of stuff. You don't have to worry about nice error message. If there is an illegal value in a hidden form field, either there is a bug or someone is making an attack.