Mail form: Validating and avoiding header injection problems

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

but the way it is could be exploited ??
Depends on were everything is coming from. If this is all the code there is, $recipientmail = $p_inquiry; is not validated at all. So under certain circumstances someone can send any mail to any recipient.

Checking for the length of $yourmail is good, but I should definately add other validation methods to that as well. Check if it's a valid email address, contains newlines, etc.

Javascript can easily be disabled, so you cannot trust that. Javascript validation is only something you should/could add on top of the server side validation to make the forms easier to use for regular users. (if they make a silly mistake they don't have to wait for the server to return an error message)
User avatar
Toneboy
Forum Contributor
Posts: 102
Joined: Wed Jul 31, 2002 5:59 am
Location: Law, Scotland.
Contact:

Post by Toneboy »

I'm seeing how rusty I am here! Thanks for your help with this matthijs, it's much appreciated.
duk
Forum Contributor
Posts: 199
Joined: Wed May 19, 2004 8:45 am
Location: London

Post by duk »

matthijs wrote:
but the way it is could be exploited ??
Depends on were everything is coming from. If this is all the code there is, $recipientmail = $p_inquiry; is not validated at all. So under certain circumstances someone can send any mail to any recipient.

Checking for the length of $yourmail is good, but I should definately add other validation methods to that as well. Check if it's a valid email address, contains newlines, etc.

Javascript can easily be disabled, so you cannot trust that. Javascript validation is only something you should/could add on top of the server side validation to make the forms easier to use for regular users. (if they make a silly mistake they don't have to wait for the server to return an error message)
yes in fact javascript could be disabled in the browser... humm thats a good point...

what ive tried to protect is the 4th field of mail() function where people could eject more emails and stuff.. the 1st field of mail() function, in this case could go everywhere you right but just for one per each time correct ?

you said to check for new lines... but if i check for the lenght of the email he can put how much \n he wants, but the form is just submited if is less then 30 and if is correctly validated... and lets imagine its validated with php, since i didn't remember about that javascript could be disabled easily.

but in fact this litle lenght check could protect me against header injection in the 4th field of mail() function...
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

but in fact this litle lenght check could protect me against header injection in the 4th field of mail() function...
In most cases an emailinjection attempt will be stopped by your method of restricting the length field.

However, what if someone - a normal user - has a very long email address? He or she gets an ugly error message or if not doesn't even know the mail has not been sent.

And I think the method is not that solid. For example:

Code: Select all

"j@te.com%0ACc:bloke@site.xxx"
will pass the length check.

the thing with input validation is you want it to be as solid as possible. Why use a method that "probably will work most of the times" instead of a secure one? And by using something as easy as ctype_print() you will be absolutely sure the header's do not contain newlines or carriage returns. And then a regular user with an email address of 40 characters is able to use your services.

But I must add to this that when you want a certain input field to be an email address, the first thing you should do is find a good email regex pattern and use that to check the email field. A good regex will catch most if not all attempts at email injection. Only after you've done that, use the ctype_print as an extra layer of security, just to be sure.
duk
Forum Contributor
Posts: 199
Joined: Wed May 19, 2004 8:45 am
Location: London

Post by duk »

i agree with you...

my only point was to prevent that someone could put undred of mails in my $yourmail form... that was my only point, and just because to the account in the webhost not get canceled because of a spam abuse, or something like that...

off course i agree that the validation is not correct but at least stops what i want...
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

duk wrote:off course i agree that the validation is not correct but at least stops what i want...
But multiple people have shown that it doesn't stop what you want. If someone can get an exploit through, it doesn't matter if it is 20-characters limited: With the exploit, they can go far beyond that!

Worse, it does something you don't want - locks out legitimate users with real email addresses. Consider gmail. While *right now*, you can use username@gmail.com, that may not last forever (long story here - pm if you want details).

As a result, it would end up being username@mail.google.com - four characters longer than your limit - a very common thing.

Worse, if you have a user with a multi-byte string, such as native characters from russia, china, ireland, and so forth, its even less!

Limiting the email length solves none of your problems:
- It does not reliably stop multiple email addresses from being entered.
- It does not prevent attacks

Limiting the email length causes new problems:
- It rejects reasonably long email addresses that ARE valid
- It rejects practically any email address with MBstring native characters.

I'd say thats a clear "not good" in every sense, especially when the alternatives are so easy to install, and effective.
duk
Forum Contributor
Posts: 199
Joined: Wed May 19, 2004 8:45 am
Location: London

Post by duk »

humm thanks for your post, i'll spend more time on that and do the correct validations :D
Post Reply