On November 5, 2002 at 16:58, Gunnar Hjalmarsson wrote: >> * The initial BEGIN block is probably not needed. Fatal messages >> should be sent a log file to avoid any potential sensitive >> information showing up in someone's browser. Error messages the user >> see should not be some Perl error message, IMHO. > >Please note that the script is intended to be password protected in some >way, and the "user" can be assumed to have at least FTP access. (I made >a change, so that the 'fatalsToBrowser' routine is not imported when >running the refresh() routine, which anybody can do.) > >I have tried to make the installation easy, and error messages in the >browser is undoubtedly convenient when you are installing a CGI script. >I could of course import the 'carpout' routine instead of >'fatalsToBrowser', or do something similar, but I don't understand the >reason for your concern.
All this sounds reasonable. I was just considering the case where something was misconfigured, so errors could happen before any password checks were performed. This could allow someone else to see error messages from the CGI. I do not think it is anything major. Maybe for a later version of your script, you could have an option that allows errors to the browser or to a log file. >True. I didn't use password protection here, since I wanted to make a >simple pipe from for instance a .forward file possible. I'd then make it configurable. By default, password check is done, but then a configuration variable can be set for those that want to bypass it. Generally, try to go with the more secure approach, but allow configurability for those who are willing, and conscience, to take the risk. >> This appears to allow someone to do a DoS against the the popserver >> ($pophost) > >Not sure what you mean by that. DoS = Denial of Service. A malicious hacker could pound the CGI script with archive update request. This would then cause alot of traffic to the POP server, which could cause denial of service problems and disable any archive updates. >You may think I'm naive, but to some extent I simply rely on >hackers/crackers/whatever having more exciting things to do than causing >some minor inconvenience for somebody who maintains a mailing list >archive. ;-) This is a common mistake made by everyone (including myself). Most people think they are not worth hacking, but it happens all the time. You may not care about your archives, but someone else using your script may. There are alot of script kiddies out there that like to screw with stuff, just cuz. >> * The updatembox() could be written to prevent a large amount of >> memory getting used. At a mimimum, store the passed in message data >> into a single scalar >> ... >> Note, an array containing each line of a message takes up more >> memory than a single scalar containing the entire message text. > >So far I understand, and now STDIN is stored in a scalar. But I haven't >used the code you suggested in this respect, since I'm not comfortable >with references in Perl, and I avoid using code I don't understand. > >If you can explain what the point would be, I'd be happy to do some >reading. :) The main reason is to reduce memory usage by not storing the complete data in memory and references could be used to avoid unnecessay copying of data (references are also required for complex data structures like an array of hashes or a hash of arrays). Reference usage could also protect from a DoS where a hacker uploads megabytes of data to the script. You may want to consider adding a max upload size parameter to check against CONTENT_LENGTH, and abort the request if CONTENT_LENGTH is too large (I'd add this feature independent of using references or not). References in Perl are not that complicated. They are much better than dealing with pointers in C, since in C, you can really screw yourself. If you have time, read the perlreftut and perlref manpages. They should help you in getting started with references. >> * In the shell() routine, you may want to use shellwords.pl. ... I'm >> not sure if anyone has bothered to make a module out of it. > >Did that. I found Text::Shellwords in CPAN, but it seems totally >redundant to me, since shellwords.pl only includes one subroutine. On >the other hand, it was Lincoln Stein who wrote it, so I guess there is a >sensible reason for its existence... My guess is that Text::Shellwords would replace shellwords.pl at sometime. However, Text::Shellwords is not included with the standard Perl distribution while shellwords.pl is. I do know why Lincoln didn't just copy the shellwords.pl implementation in Text::Shellwords. I'm slowly working on v2.6.0 of MHonArc. When I think I am getting near a release date, I will post a message to the dev list. You can then remind me about your mhastart.pl and insure I get the latest copy before the release is made. I recommend that you run pod2html on your script and make the output available on your site. This way, people can read the docs before downloading to see how it works. --ewh --------------------------------------------------------------------- To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
