PHP mail()

Security issues

[macmuso]

Hey

I have a simple mail script, eg...

$message = '$part1' \n '$part2';
mail();
header(Location:);

...which is linked through from an (also simple) html form. What are the security issues with this? Is there anything malicious users can do that will cause horrible disease and plague in my server?

[dingman]

Depends on the arguments to mail(). If there is any user-supplied data, there is potential for abuse, though it can be mitigated. (Even "hidden" inputs count as user-supplied, too.)

If the user specifies the destination e-mail address, they can send mail to anyone they like. If they can specify all or part of the message contents, then a user can stick spam or some virus/trojan payload into the message body. If both, they you're running an open relay by accident, and may find your server hijacked to send spam.

The solution to these problems is strict input checking. For many forms, you can even hard-code the address to mail to, which limits exposure to whoever collects the form input and makes the form unappealing to spammers because there's only one target address they can hit with it. Don't ever count on the forms you write for enforcement of the constraints you want, nor on javascript you might add to the page. Verify everything server-side, because that's the only environment you can trust.

[macmuso]

Ok, the setup at the moment is just two fields, and thats
<textarea name="message">
and
<input type="text" name="from">

(message body and reply-to address)

The rest (destination, subject) are already set up. You mentioned "a user can stick spam or some virus/trojan payload into the message body" - is this possible at the moment?

[dingman]

If you're not munging $message before you send it, then yes, someone could insert something malicious into the body of the e-mail, and it might cause you some grief depending on what mail program you use to read the resulting message. You are, however, safe from being used as a spam relay.

[macmuso]

What is munging? And how do it do it?

[dingman]

$ dict munge 
2 definitions found 
                                         
From Jargon File (4.3.0, 30 APR 2001) [jargon]: 
                                         
 munge /muhnj/ vt. 1. [derogatory] To imperfectly transform information. 
   2. A comprehensive rewrite of a routine, data structure or the whole 
   program. 3. To modify data in some way the speaker doesn't need to go 
   into right now or cannot describe succinctly (compare {mumble}). 4. To 
   add {spamblock} to an email address. 
                                       
   This term is often confused with {mung}, which probably was derived 
   from it. However, it also appears the word `munge' was in common use in 
   Scotland in the 1940s, and in Yorkshire in the 1950s, as a verb, meaning 
   to munch up into a masticated mess, and as a noun, meaning the result of 
   munging something up (the parallel with the {kluge}/{kludge} pair is 
   amusing). The OED reports `munge' as an archaic verb meaning "to wipe (a 
   person's nose)". 

I was using deffinition 3 :) How you transform the user data depends on what you want to protect against and what you want the message to be able to contain. One possible approach would be to delete any character other than [A-Za-z0-9@\.\?\s\n], leaving you with very simple text, space, newlines, and not even much punctuation. Bland, to say the least, but someone would be pretty hard pressed to squeeze something obnoxious into that character set. Exactly what you allow and don't, though, is your own call based on what you need to get out of the input.

[macmuso]

Ok, say I just want to make sure I don't get attachments or malicious code. In other words, I just want the text, although periods, commas and quotation marks could stay. What's the most simple way to do it?

[dingman]

It really depends on how your mail software behaves. There's no way for someone to set headers in the message using the form you have described, so if your mailer requires a mime-type header to consider processing a message as HTML or multipart/whatever, then you're safe as it is. I don't know off the top of my head how different mail programs behave, so I'm really not sure what limitations each one might need to eliminate potentially dangerous content. If I were doing this for my own use, I'd either just set up something extemely strict, like what I described above, or send myself several slightly malformed messages to see what my mailer did with them and find ways to prevent that category of message from getting through.

I might also do something like calling htmlentities() on the whole message, on the theory that it would change enough important characters to make any executable content un-executable. That's not robust by any means, but it would be a decent heuristic.

[jaski]

Ok, say I just want to make sure I don't get attachments or malicious code.

Its not possible to send attachements through a <textarea> so I think you can stop worrying about attachments .. also malicious code will not execute even if pasted and sent if it is going to come through as plain text.

If you are getting it as html, you can use some thing like this

$string = strip_tags($string, '<a><b><i><u>');

it will strip html tags except those in the second argument ..

you can see more about this here
[php.net...]