After a quick perusal it seems the replacement form's greatest contribution seems to be to limit the number of recipients that may be emailed at any one time. There seem to a number of other improvements and it looks like the code is updated more to what is recommended here. I do understand the objections to Matt's style, after all he wrote this stuff when he was just 14 and Perl has come a long way since then. I don't share the animosity, after all he has done a great deal to popularize Perl. It's just too bad he did it with poor code and continues to write bad code.
-----Original Message----- From: John Brooking [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 3:53 PM To: cgi Subject: Re: Matt Wright's formMail I must confess I'm not intimately familiar with the script in question, so I don't completely understand what the code snippet that drieux included does, therefore how it is or is not sufficiently secure. However, I have some more general comments in the way of clarification. It seems to me that the *fact* of using the referers environment variable is not the security risk, but that relying on it *only* is the risk. My introduction to this issue was getting publicly flamed on perl beginners last summer partially for not knowing this. (Don't worry, the burns healed quickly.) Since then, I've at least read enough to know that anyone with the LWP module or any other HTTP API in any language can build a web client with any referer header they want. But I would think that means that using referers in itself is not inherently dangerous, only thinking that it's doing you any good security-wise is. The danger that this ignorance makes possible depends on what the rest of your script does with the input it gets. Encoding data in the URL - well, all "GET" parameters work that way, in the broadest definition of the term "data". The question is, what does the script *do* with that data? As all good readers of the security chapter of O'Reilly's "CGI Programming with Perl" (among others) will know, the biggest security hole with user input is when that data is used for input to a shell process. Is that what Matt's script does? If so, is the generally approved work-around one of the two fix-ups recommended by that book: (1) filter the input string to disallow "bad" characters such as shell escapes, or better yet, (2) use a combination of fork and exec rather simply opening a pipe to a process? How does the NMS replacement code handle this, and what do you all do in similar cases? - John --- drieux <[EMAIL PROTECTED]> wrote: > > On Monday, May 13, 2002, at 09:21 , Camilo Gonzalez > wrote: > [..] > > The problems seem to be that it uses the Referer > environmental variable to > > exclude spammers and it gives the option of > encoding data in the URL. I've > > been told both are considered security risks. My > ISP does not think even > > the > > latest release addresses these issues and refuses > to let Formmail on its > > servers. > [..] > > in the main I have heard the same things - I can > appreciate that > ISP's are at liberty to do as they will - I was just > trying to > track down my exposure - given as our ISP is running > v1.92.... > > it could be that if one's ISP is doing a lot of > virtual hosting > then the simplification of > > @referers = ('wetware.com','199.108.16.17'); > > could get messy.... hence the following guard code: > > sub check_url { > > # Localize the check_referer flag which > determines if user is > valid. local($check_referer) = 0; > > # If a referring URL was specified, for each > valid referer, make sure > # > # that a valid referring URL was passed to > FormMail. > # > > if ($ENV{'HTTP_REFERER'}) { > foreach $referer (@referers) { > if ($ENV{'HTTP_REFERER'} =~ > m|https?://([^/]*)$referer|i) { > $check_referer = 1; > last; > } > } > } else { $check_referer = 1; } > > # If the HTTP_REFERER was invalid, send back > an > error. if ($check_referer != 1) > { &error('bad_referer') } > } > > is not sufficiently robust enough???? > > where that code is preventing spamming is with: > > @recipients = &fill_recipients(@referers); > > sub fill_recipients { > local(@domains) = @_; > local($domain,@return_recips); > > foreach $domain (@domains) { > if ($domain =~ /^\d+\.\d+\.\d+\.\d+$/) { > $domain =~ s/\./\\\./g; > push(@return_recips,'^[\w\-\.]+\@\[' . > $domain . '\]'); > } else { > $domain =~ s/\./\\\./g; > $domain =~ s/\-/\\\-/g; > push(@return_recips,'^[\w\-\.]+\@' . > $domain); > } > } > > return @return_recips; > } > > and I have tested this anti-spam piece - and the > only thing that survives is aimed where it is > suppose to go. > > As for 'using old perl' - I'm not sure that is an > 'issue'? is it? > since this is running in a 5.6 environment..... > > or am I missing something here??? > > > ciao > drieux > > --- > > > -- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > ===== "When you're following an angel, does it mean you have to throw your body off a building?" - They Might Be Giants, http://www.tmbg.com ---- Word of the week: Serendipity, see http://www.bartleby.com/61/93/S0279300.html __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
