NYCPHP Meetup

[Hans Zaunere]

Dan Cech wrote on Monday, September 19, 2005 8:24 AM:
> Jeff & list,
> 
> I believe I managed to avoid weighing into the various debates raging
> back and forth in the thread.
> 
> The idea of checking for particular email addresses in the mail logs
> does seem pretty naive, especially as they are such a throwaway item
> these days.

This is absolutely true.  However, it is an easy first step to detect the
use of this exploit.  It's not exhaustive by any means (as only recoding
some key input validation code would be), but it can be a first step to
catching this early on.

> Personally I'm of the opinion that these kinds of forms should require
> inputs that are supposed to be email addresses to look like email
> addresses.  Not only will that remove the possibility of this exploit,
> it will also cut down (ever so slightly) on malformed addresses being
> sent through to the mail subsystem.  Good user feedback for 'invalid'
> addresses should allow anyone using the form to 'correct' them, so I
> see little point in blindly accepting something that isn't obviously
> an email address.
>
> The other common vulnerable field seems to be the Subject, though I
> see very little reason not to restrict that (or any other
> non-address) field to something like
> /^([-a-z0-9!@#$%^&*()_\[\]{}\\|;:'",.<>\/?+= ]+)$/i, especially
> considering the fact that non-ascii characters are usually frowned
> upon in email headers. 
> 
> Also, correct me if I'm wrong but I believe the %0A encoding is purely
> used in the request string, once it gets into PHP it will just see
> either \n or \r, the literal string %0A does not pose any risk to
> emails as a string itself.

The combination of email address checking and subject field checking is one
way of preventing this exploit.  And of course, it's always a good idea to
validate input, and prevent odd characters from entering your runtime
environment.

However for this particular exploit, it's easy to prevent.  It's simply not
possible for this exploit to work without the Content-Type: string.
Searched for, in a case-insensitive manner, across all submitted form
fields, will detect and thrawt this exploit immediately.

The only caveat that I've found is when character encoding might be
involved.  I haven't seen that it's very common, but it's out there:

http://www.faqs.org/rfcs/rfc2047.html

Does anyone have access to a SMTP server that is known to work with
non-ASCII headers for testing?

And as an FYI, Wikipedia scores again with an excellent resource on MIME and
email from a technical perspective:

http://en.wikipedia.org/wiki/MIME



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