A redcent thread I started discussed the fact my mostly self-made contact form at http://twistedmelon.com/contact/contact.php was being used by to inject headers and send out mail.

I have since implemented a number of checks and balances to deny header insertion through carriage returns and new lines on all fields where we accept user input. This should make it so no "To:" field can be input and the mail is only ever sent to addresses internal to the script.

We also check the message body for MIME and Content-Type headers. Yesterday I tightened up the message content area by also failing any message that includes so much as a single "http" or "href" within its text.

Today I received a couple of messages that look to be from a spammer, but they were properly filled out and sent to me - this isn't a problem. But just now I've received two bounces back which indicate the messages were also sent to someone else - or such an attempt was made that went farther than my script all the way to the mail system.

I've tested the forms of injection I've read about but can't for the life of me break the measures I've got in place.

Anyone care to help me figure out where the problem lies?

On the bounces the "To:" field comes back blank with no Bcc or cc fields included.

Why don't you have this script populate a database with every request it gets so you can see what the bad guys are doing?

Yeah, just log *everything* so you can see *exactly* what's going on, rather than having to guess.

-ml

Would you like a simple C-program that maintains a (single) circular log file? Callable from any CGI-script? Requires a POSIX environment (eg. Solaris, Linux, OS/X, ..).

Attached, for anyone else interested in it. Written by me.

-ml

That's why I post here. To get advice on the obvious.

Instead of logging to a file I've formatted everything that's used to make the original email and tossed that into the body another email I send to myself at the same time. So far it looks like everything that would be logged to a file is coming through OK. With the added benefit that I don't have to FTP the file to read it.

I made some small alterations to the mail script this afternoon as well, so it will be interesting to see if anything else comes through.

Thanks Mark, I didn't see your previous message until now.

I discovered that nothing is being injected into the headers. But.... What the scammers are likely doing is substituting the value of the "to" variable I use. Since this is just used internally to reference a hard-coded list, their attempt doesn't go anywhere.

And another but... I noticed that I forgot to handle the default case - if the "to" contained any content that did not match my reference list. Oops! That was causing the abusers' emails to go out with no destination which would generate a bounce back to me.

This is now taken care of by blanking the variable if it doesn't match my list, which in turn causes it to be trapped by the error handling I already had in place. That causes the form to stay where it is and show a visible warning pointing out the form is incomplete.

Now it should only bee possible for abusers to spam my own addresses with this form. And I'm curbing that by restricting links within the message body and can also block by IP if I notice any trends.

Phew.