Tad McClellan said:
Replace the 2 lines that I showed you, and your working program
(with the hokey library) should continue to work (with CGI.pm).
I did that, and it works very well. I did not really understand the package
concept, but it is really very much like the USES statement in Delphi. But I
didn't realize that the CGI package had the same function as the code in my
script for handling the vars.
With CGI.pm you would test it from the command line thus:
someprog name=Paul email='(e-mail address removed)'
Simple!
I was able to get that to work on my local machine, but there is a Full_Name
variable that has spaces in it, and I did not find any way to use it in
command line parameters. It. is important because I am using that as a form
of password. But I could change it for testing
^^^
^^^
Past tense?
I am quite certain that you are being overly optimistic there.
The code you showed some time ago was vulnerable to a Denial Of
Service attack. Have you mitigated that one somehow?
I'm not sure how it is vulnerable to a DOS attack, or if that is likely to
occur. This form will be accessed by only a few Sierra Club members, and the
correct Full_Name must be provided in order to proceed. Otherwise it returns
"Unauthorized User". If the correct name is given, then the event
information is verified for reasonable values (in the Submission Form's
JavaScript), before it will make the HTTP request to the CGI script.
Of course anyone could look at the HTML source and find the URL of the perl
script so it could be accessed from another site. Perhaps the perl script
with the passwords in the cgi-bin could be examined and exploited in some
way, but it would just send emails to me indicating new events have been
posted, and the email includes the website URL where it originated (which
should be my hosts). The Email provided is only for further identification
of the senders.
You will be cracked. I see it coming...
Perl has a feature called "taint checking" that can help mitigate
that risk:
perldoc perlsec
I am concerned about security and I'd like to know if this is really likely
to be subject to a malicious and debilitating attack, and find ways to
mitigate the damage or protect it. I'll look into the "taint checking"
The fix is ass backwards.
It specifies "bad" characters.
The proper approach is to specify "good" characters.
That is, you don't try and idenfify what might be harmful (what if you
miss one?) you instead specify what you will allow.
Since you are doing something with mail, you have surely searched
the Perl FAQ for that term
perldoc -q mail
and have seen the answer to
How do I check a valid mail address?
I trust.
If not, then use the FAQ Luke!
I can see that there is a huge amount of information to assimilate and this
may be more of a challenge than I want to tackle. But I'm learning a lot and
it's actually fun when I make progress. Sometimes I just don't know what to
look for or where to find it. I generally check the FAQ and do a web search,
but sometimes the resources are not very good, as was the case with this
simple mailer that I used and modified.
Now I have been working on the HTML submission form and JavaScript to make
sure the data is reasonable. I suppose it's best to do that at that level so
that the events will be consistently formatted. I added a simple date picker
that works pretty well, and I also found a simple calendar, but a fancier
version was just too complex. And of course that is OT for this NG, but it
helps to see the big picture from the input provided by the user to the
final usage in the website.
I appreciate the help, and I understand your frustration with my bumbling
attempts at getting this working.
Paul
