[thelist] injection attacks on php contact form

[Hans Zaunere]

Kasimir K wrote on Wednesday, November 30, 2005 4:06 AM:
> 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)

New York PHP has developed a PHundamental to address this:

http://www.nyphp.org/phundamentals/email_header_injection.php

We've seen this attack in the wild for some time - apparently just scanning.
Now it appears as if it may be trying to take advantage of vulnerable sites.
Attacks have increased dramatically.


---
Hans Zaunere / President / New York PHP
   www.nyphp.org  /  www.nyphp.com