[thelist] injection attacks on php contact form

[Kasimir K]

Garth Hagerman scribeva in 2005-11-29 23:27:
> 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]

> 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.)

> 3. The processing script checks for a blank user email address or one 
> from the site's domain. There has always been a standard Javascript on 
> the form which checks for credible email addresses, but the bad guys 
> have been getting around that.

Yes, because they don't use the page to send the POST request, but 
instead create artifically a forged request. I.e. they don't use web 
browsers, they use bots.

> 4. Limits on the length of subject and user email fields. The body of 
> the message can still be as long as necessary.

This helps, but potentially could cause surprises in the future.

With this problem too it helps to think simple. So, what really is the 
problem? It has two parts:
1. you have a script accepting user input, and then using some of it for 
email headers
2. some users give input that creates unwanted headers to the message

Solutions:
1. don't put any user input in email headers (this AFAIK is the only 
bullet proof method)
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)

.k


[0] http://www.w3.org/TR/turingtest/