Page 2 of 2

Posted: Tue Feb 28, 2006 6:45 am
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)

Posted: Tue Feb 28, 2006 6:53 am
by Toneboy
I'm seeing how rusty I am here! Thanks for your help with this matthijs, it's much appreciated.

Posted: Tue Feb 28, 2006 8:32 am
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...

Posted: Tue Feb 28, 2006 9:01 am
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.

Posted: Tue Feb 28, 2006 9:17 am
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...

Posted: Tue Feb 28, 2006 6:34 pm
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.

Posted: Wed Mar 01, 2006 3:57 am
by duk
humm thanks for your post, i'll spend more time on that and do the correct validations :D