[thelist] injection attacks on php contact form

Garth Hagerman hagerman at mcn.org
Wed Nov 30 18:50:21 CST 2005

Thanks to all who responded, especially Kasimir for the detailed input. 
I've been reading the linked pages and I'm well on the way to solving 
the problem.

>> 1. A graphic password that only a human user should be able to read.
> Not recommended. The protection they provide is by no means perfect, 
> and
> they cause serious accessibility problems. [0]

Yes, I've had some problems (on another form) with legitimate users who 
can't figure out my too cute password graphic.  This one is simpler and 
less cute, but still it might be confusing to some people and 
crack-able by ocr-savvy bots. I think I'll try a two digit, super 
simple, arithmetic problem with the numbers spelled out for now -- 
still an imperfect solution, but probably a better one.

>> 2. The processing script uses eregi() to look for "\n", "\r",
>> "Content-Type:", and "MIME-Version:" in the input data. If any of 
>> those
>> are found, it doesn't send the email.
> But any of those may be legitimate input in some fields, e.g. a message
> field. So check these only for data that is going to the header of the
> mail (e.g. sender's name or email address). And just checking for a
> colon : would actualy suffice, and that would catch other headers too,
> especially the Cc: header. (Check for newlines is good and necessary 
> too.)

It seems much more likely that a legitimate message would have a colon 
than "Content-Type:" or "MIME-Version:" The only time I could see those 
as legitimate is in a technical context like this where those are 
legitimate terms for discussion. My clients are realtors, performing 
arts companies, and small businesses; it'd be a stretch to imagine 
those terms used in a legitimate inquiry.

I've received three more bad emails since I posted the question 
originally; now I've added "Cc:" and "Bcc:" to the verboten list.

> Solutions:
> 1. don't put any user input in email headers (this AFAIK is the only
> bullet proof method)

Yuck. That's not so good for my clients. They can't just click on 
"reply" to repond to an inquiry, and the subject line would have to be 
a generic "inquiry from your web site" or some such.

> 2. if you can't do 1), then remove any unwanted headers - that is input
> with newlines and colons (all header lines start with alpha characters
> followed by a colon)
Perhaps, after I reject the nastry strings, I'll do a string_replace() 
and replace colons with double dashes or something else inocuous. That 
should add an extra layer of protection without rejecting legitimate 
inquiries; perhaps then I can safely get rid of the math quiz, or 
password graphic, or whatever.

    thanks again,

                            * * * * * * * * * * * * * * * *
                                my online portfolio


More information about the thelist mailing list