[Q] mail() & security

[Eric]

One of the first rules of doing web development is to never trust user
input.

So, my question is how this may affect the usage of the mail() function
within PHP.

Obviously, one can (fairly easily) verify that what one is passing in
the TO parameter is a valid e-mail address.

What is recommended with respect to the subject & message parameters?

One potentially good function to run them through is strip_tags.

[Daniel Tryba]

Re: [Q] mail() & security

Eric <egusenet@veriz on.net> wrote:[color=blue]
> Obviously, one can (fairly easily) verify that what one is passing in
> the TO parameter is a valid e-mail address.[/color]

_A_ valid email address, but is _the_ correct address?
[color=blue]
> What is recommended with respect to the subject & message parameters?[/color]

So you let a mail script accept the to, subject and message body? You
just described described a spam relay.

If you are using this for a feedback form this is not the way to go, to
and subject should be fixed. The body shouldn't be send to the user
entering the data, you a plain confirmation that the message was
received.
[color=blue]
> One potentially good function to run them through is strip_tags.[/color]

What would that accomplish? A good MUA shouldn't trust the content of any
mail (unless the users tells it to ofcourse).

[Eric]

Re: [Q] mail() &amp; security

Daniel Tryba <partmapsswen@i nvalid.tryba.nl > wrote:
[color=blue][color=green]
> > One potentially good function to run them through is strip_tags.[/color]
>
> What would that accomplish?[/color]

The removal of various destructive things which one could bury in a tag
which would then be interpreted by an e-mail application capable of
rendering HTML. For example, an img tag which could result in the
downloading of unwanted images.

Seems like a good idea, but you seem to feel it would be pointless? Why?
[color=blue]
> A good MUA shouldn't trust the content of any
> mail (unless the users tells it to ofcourse).[/color]

So, then, if you wanted to allow a user to enter some text into the body
of a message, what would you do to protect the recipient of that
message?

[Daniel Tryba]

Re: [Q] mail() &amp; security

Eric <egusenet@veriz on.net> wrote:[color=blue][color=green][color=darkred]
>> > One potentially good function to run them through is strip_tags.[/color]
>>
>> What would that accomplish?[/color]
>
> The removal of various destructive things which one could bury in a tag
> which would then be interpreted by an e-mail application capable of
> rendering HTML. For example, an img tag which could result in the
> downloading of unwanted images.
>
> Seems like a good idea, but you seem to feel it would be pointless? Why?[/color]

My MUA already provides this protection and AFAIK any decend MUA does
that. Added bonus is that I can still tell it not to "protect me", and
thus show the images when I want it to.
[color=blue][color=green]
>> A good MUA shouldn't trust the content of any
>> mail (unless the users tells it to ofcourse).[/color]
>
> So, then, if you wanted to allow a user to enter some text into the body
> of a message, what would you do to protect the recipient of that
> message?[/color]

Advise them a decent MUA, and fitler out html messages. My smapfilter is
trained to tag htmlonly mail as spam (except when explicitly
whitelisted), shows text/plain by default and
will not fetch external links by default.

[Eric]

Re: [Q] mail() &amp; security

Daniel Tryba <partmapsswen@i nvalid.tryba.nl > wrote:
[color=blue]
> Eric <egusenet@veriz on.net> wrote:[color=green][color=darkred]
> >> > One potentially good function to run them through is strip_tags.
> >>
> >> What would that accomplish?[/color]
> >
> > The removal of various destructive things which one could bury in a tag
> > which would then be interpreted by an e-mail application capable of
> > rendering HTML. For example, an img tag which could result in the
> > downloading of unwanted images.
> >
> > Seems like a good idea, but you seem to feel it would be pointless? Why?[/color]
>
> My MUA already provides this protection and AFAIK any decend MUA does
> that. Added bonus is that I can still tell it not to "protect me", and
> thus show the images when I want it to.
>[color=green][color=darkred]
> >> A good MUA shouldn't trust the content of any
> >> mail (unless the users tells it to ofcourse).[/color]
> >
> > So, then, if you wanted to allow a user to enter some text into the body
> > of a message, what would you do to protect the recipient of that
> > message?[/color]
>
> Advise them a decent MUA, and fitler out html messages. My smapfilter is
> trained to tag htmlonly mail as spam (except when explicitly
> whitelisted), shows text/plain by default and
> will not fetch external links by default.[/color]

Unfortunately, your latest comments are clearly entirely irrelevant to
the discussion which is what useful things can be done to process text
sent to the body and subject parameters of the mail() function to
prevent anything annoying/destructive from being sent to the recipient.

If you have any comments related to the topic of this thread, please let
me know.

For those who may be interested, in a simultaneous discussion which took
place elsewhere, one other option was presents which would be to run the
text through the htmlentities function.

Like strip_tags, this would prevent any annoying/destructive html from
being rendered and have the addition benefit of knowing whether or not
someone attempted to send something that was annoying/destructive.

However, I, personally, will likely stick with strip_tags. Although,
this function could remove useful text, it would also not force the
recipient to try to parse something not particularly human readable.

It would seem the sending of things that strip_tags or htmlentities
would stop is the only thing that one would need to be concerned with.

[Daniel Tryba]

Re: [Q] mail() &amp; security

Eric <egusenet@veriz on.net> wrote:[color=blue]
> If you have any comments related to the topic of this thread, please let
> me know.[/color]

My comments should be read as: don't send text/html.

All below is unnecessary when the "html" is send as text/plain.
[color=blue]
> For those who may be interested, in a simultaneous discussion which took
> place elsewhere, one other option was presents which would be to run the
> text through the htmlentities function.[/color]
[snip]

BTW sending html in text/plain scores extra points in spam filters.