Just because people are supposed to use your form, does NOT mean that they have to! In other words, If they know the name and location of your script, whether it be a php, perl, shell script, or whatever, and they know the variable names passed to it by your form, they can use whatever method they choose to post data to it! Unfortunately there's not a lot that can easily be done to guard against this. However, what can be done, are some sanity checks within your script which is far more effective anyway. Doing things like disallowing dangerous shell escapes, back ticks, "sanitizing" all variables passed in, etc. are some of the more obvious things to incorporate within your script. These can easily be accomplished using simple REGEXP's.
A couple of years ago, I wrote a perl script that essentially did what yours does; sent e-mail from a Web form on one of my Websites, to my admin e-mail account. I didn't write it with security in mind and unfortunately someone was able to exploit it by posting some custom form data to it, that contained a command with back ticks! Luckily I noticed it right away, took it offline, and fixed it. The extent of the damage was minimal as I had taken the time to enforce execution of all CGI's within a very controlled environment. Had I not, the damages could have been far worse!
When I began investigating the incident, I had relatively little data on which to go but once I figured out what had happened, I was curious! The next revision of my mailer script contained some extra code to log, very verbosely, any and all "nonstandard" data passed to my script. After a few more malicious attempts against my script, it became crystal clear as to what data strings were being tried against my script! You may or may not want to incorporate something similar on yours but it does give a little insight as to what the bad guys are doing.
Anyhow, I hope at least some of this info was useful. If not, maybe you enjoyed my little story! Good luck with it either way!
k_Rob - kk7av
