By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,602 Members | 1,473 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,602 IT Pros & Developers. It's quick & easy.

mail() injection, am i safe?

P: n/a
Hi,

I was looking at mail injection,
http://securephp.damonkohler.com/ind...mail_Injection

And I was wondering if my mail(...) was safe.

I ask in a form for
1 Name
2 Email address
3 Subject
4 Comment/Message

I then build one message by putting all of the above together.
So even if there was injection, it is all in the body of my message, right?

I then use mail(...) as per normal with my hard coded "To:" and "Subject:"

Is that a fairly safe way?

How should I parse my form to prevent malicious code, (Script? eval?)

Many thanks for your input.

Simon


Nov 11 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a
They can also inject stuff in the "Subject" line..

You should run your name, e-mail and subject lines through a test function
like mine:

function isUnsafe($str)
{
if (eregi('Content-Type', $str))
return true;

if (eregi('multipart/mixed', $str))
return true;

if (eregi('bcc:', $str))
return true;

return false;
}

Probably isn't sufficient, but the "Content-Type" and "multipart" stuff is
dangerous.

You should also hardcode the headers yourself with "Content-Type:
text/html".

HTH
Lisa
"Simon" <sp********@example.com> wrote in message
news:3t************@individual.net...
Hi,

I was looking at mail injection,
http://securephp.damonkohler.com/ind...mail_Injection

And I was wondering if my mail(...) was safe.

I ask in a form for
1 Name
2 Email address
3 Subject
4 Comment/Message

I then build one message by putting all of the above together.
So even if there was injection, it is all in the body of my message,
right?

I then use mail(...) as per normal with my hard coded "To:" and "Subject:"

Is that a fairly safe way?

How should I parse my form to prevent malicious code, (Script? eval?)

Many thanks for your input.

Simon

Nov 11 '05 #2

P: n/a

"Lisa Pearlson" <no@spam.plz> wrote in message
news:43**********************@dreader16.news.xs4al l.nl...
They can also inject stuff in the "Subject" line..

You should run your name, e-mail and subject lines through a test function
like mine:

function isUnsafe($str)
{
if (eregi('Content-Type', $str))
return true;

if (eregi('multipart/mixed', $str))
return true;

if (eregi('bcc:', $str))
return true;

return false;
}

Probably isn't sufficient, but the "Content-Type" and "multipart" stuff is
dangerous.

You should also hardcode the headers yourself with "Content-Type:
text/html".

HTH
Lisa


Thanks, but my subject is also hard coded, in fact, everything is hard
coded.
I place everything together into the body of the message itself.

My question would be more, what can they inject in the actual body of the
email?

Simon
Nov 11 '05 #3

P: n/a
"Lisa Pearlson" wrote:
They can also inject stuff in the "Subject" line..

You should run your name, e-mail and subject lines through a test function
like mine:

function isUnsafe($str)
{
if (eregi('Content-Type', $str))
return true;

if (eregi('multipart/mixed', $str))
return true;

if (eregi('bcc:', $str))
return true;

return false;
}

Probably isn't sufficient, but the "Content-Type" and "multipart" stuff is
dangerous.


This was discussed here just a few days ago:
http://groups.google.co.uk/group/com...hread/689f9ef1
5372dfc1/7da226ecec244dea

Generally it's better to check that the submitted data conforms to a *valid*
pattern than to check it against specific *invalid* patterns. Among other
things, your routine won't detect any linefeeds, which provide a simple
means of inserting additional headers (and even body content) into an email.

So for example, if you think a valid "Subject" should consist of between 1
and 200 characters with ASCII codes of 32 or more (i.e. no control
characters), then *don't accept anything else*.

You should also make sure your script cannot be affected by user input that
contains, for example, quotation marks or HTML tags. For example, suppose
your error routine consists of something like this:

<?
:
:
$subject = $_GET["subject"];
if (!isValid($subject))
die("<P>Sorry, but \"$subject\" is not a valid subject string.</P>");
:
:
?>

If you haven't checked that $subject contains no HTML tags, then the hacker
can insert whatever he likes into your HTML, such as a link to some other
website, or piece of Javascript that redirects the page automatically. That
would be a serious problem if the page was part of an online banking site
(Google for "phishing" if you can't figure out why).

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Nov 11 '05 #4

P: n/a
Just make sure that you're stripping linefeeds/carriage-returns from
all the fields.

Nov 11 '05 #5

P: n/a
I agree, but some characters are valid in names in some countries, like
"Gert-Jan v/d Boer". So sometimes it can actually be harder to know what to
expect, than it it to know what is definitely wrong (like specific key words
or SQL statements).
"Philip Ronan" <in*****@invalid.invalid> wrote in message
news:BF9A6AFB.3AB44%in*****@invalid.invalid...
"Lisa Pearlson" wrote:
They can also inject stuff in the "Subject" line..

You should run your name, e-mail and subject lines through a test
function
like mine:

function isUnsafe($str)
{
if (eregi('Content-Type', $str))
return true;

if (eregi('multipart/mixed', $str))
return true;

if (eregi('bcc:', $str))
return true;

return false;
}

Probably isn't sufficient, but the "Content-Type" and "multipart" stuff
is
dangerous.


This was discussed here just a few days ago:
http://groups.google.co.uk/group/com...hread/689f9ef1
5372dfc1/7da226ecec244dea

Generally it's better to check that the submitted data conforms to a
*valid*
pattern than to check it against specific *invalid* patterns. Among other
things, your routine won't detect any linefeeds, which provide a simple
means of inserting additional headers (and even body content) into an
email.

So for example, if you think a valid "Subject" should consist of between 1
and 200 characters with ASCII codes of 32 or more (i.e. no control
characters), then *don't accept anything else*.

You should also make sure your script cannot be affected by user input
that
contains, for example, quotation marks or HTML tags. For example, suppose
your error routine consists of something like this:

<?
:
:
$subject = $_GET["subject"];
if (!isValid($subject))
die("<P>Sorry, but \"$subject\" is not a valid subject string.</P>");
:
:
?>

If you haven't checked that $subject contains no HTML tags, then the
hacker
can insert whatever he likes into your HTML, such as a link to some other
website, or piece of Javascript that redirects the page automatically.
That
would be a serious problem if the page was part of an online banking site
(Google for "phishing" if you can't figure out why).

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Nov 11 '05 #6

P: n/a
If you haven't checked that $subject contains no HTML tags, then the
hacker
can insert whatever he likes into your HTML, such as a link to some other
website, or piece of Javascript that redirects the page automatically.
That
would be a serious problem if the page was part of an online banking site
(Google for "phishing" if you can't figure out why).


Yes, so after "isUnsafe" I actually call htmlspecialchars()

Nov 11 '05 #7

P: n/a
"Lisa Pearlson" wrote:
I agree, but some characters are valid in names in some countries, like
"Gert-Jan v/d Boer". So sometimes it can actually be harder to know what to
expect, than it it to know what is definitely wrong (like specific key words
or SQL statements).


That's very true. I didn't say this was *easy* did I?

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Nov 11 '05 #8

P: n/a
Simon wrote:
My question would be more, what can they inject in the actual body of the
email?


Make sure the "additional headers" parameter ends with "\r\n\r\n" and you
ought to be fine.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Nov 22 '05 #9

P: n/a

"Toby Inkster" <us**********@tobyinkster.co.uk> wrote in message
news:40************@ophelia.g5n.co.uk...
Simon wrote:
My question would be more, what can they inject in the actual body of the
email?


Make sure the "additional headers" parameter ends with "\r\n\r\n" and you
ought to be fine.


Sorry, I am still not sure I follow,
Almost everything is hard coded, (the 'to' and the 'subject').

and the header is

"Reply-To: we*******@example.com."\n" .
"From: we*******@example.com."\n" .
"Return-Path: we*******@example.com."\n" .
"MIME-Version: 1.0\n".
"Content-type: text/plain; charset=iso-8859-1\n".
"Content-transfer-encoding: 8bit\n".
"Date: " . date('r', time()) . "\n".
"X-Priority: 3\n".
"X-MSMail-Priority: Normal\n".
"X-Mailer: PHP/" . phpversion();

So are you saying I should add "\r\n\r\n" as well?

the message is created using the info given by the user. _but I don't check
that data_.
What could they inject into the message that would cause mail(...) to be
unsafe?

Thanks

Simon
Nov 22 '05 #10

P: n/a

Simon wrote:
"Toby Inkster" <us**********@tobyinkster.co.uk> wrote in message
news:40************@ophelia.g5n.co.uk...
Simon wrote:
My question would be more, what can they inject in the actual body of the
email?
Make sure the "additional headers" parameter ends with "\r\n\r\n" and you
ought to be fine.


Sorry, I am still not sure I follow,
Almost everything is hard coded, (the 'to' and the 'subject').

and the header is

"Reply-To: we*******@example.com."\n" .
"From: we*******@example.com."\n" .
"Return-Path: we*******@example.com."\n" .
"MIME-Version: 1.0\n".
"Content-type: text/plain; charset=iso-8859-1\n".
"Content-transfer-encoding: 8bit\n".
"Date: " . date('r', time()) . "\n".
"X-Priority: 3\n".
"X-MSMail-Priority: Normal\n".
"X-Mailer: PHP/" . phpversion();


next comes the $message. if the message was
\n bcc: un******@recipient.com, un******@adslfkj.com, \n
lemme tell ya bout these blue pills...

(or something like that)
You can see where that aint gonna be too cool.
So are you saying I should add "\r\n\r\n" as well?


that's supposed to make the mailing program quit with the headers and
send the rest as the message.

Nov 22 '05 #11

P: n/a
"juglesh" wrote:

Simon wrote:

Almost everything is hard coded, (the 'to' and the 'subject').

and the header is

"Reply-To: we*******@example.com."\n" .
"From: we*******@example.com."\n" .
"Return-Path: we*******@example.com."\n" .
"MIME-Version: 1.0\n".
"Content-type: text/plain; charset=iso-8859-1\n".
"Content-transfer-encoding: 8bit\n".
"Date: " . date('r', time()) . "\n".
"X-Priority: 3\n".
"X-MSMail-Priority: Normal\n".
"X-Mailer: PHP/" . phpversion();


next comes the $message. if the message was
\n bcc: un******@recipient.com, un******@adslfkj.com, \n
lemme tell ya bout these blue pills...


The php mail() function doesn't work like that. Additional headers are
passed as a separate parameter to the mail() function. There is no need to
add extra linebreaks at the beginning of the body text; PHP will do this
anyway.

If the headers have all been hard-coded like in Simon's example, then the
script is safe. There is no way the POST data can be rigged to insert
additional headers into the email.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Nov 22 '05 #12

P: n/a
Simon wrote:
the message is created using the info given by the user. _but I don't check
that data_.
What could they inject into the message that would cause mail(...) to be
unsafe?


$_POST['message'] = "BCC: me@example.com\r\n\r\nlalala";

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Nov 22 '05 #13

P: n/a
"Toby Inkster" wrote:
Simon wrote:
the message is created using the info given by the user. _but I don't check
that data_.
What could they inject into the message that would cause mail(...) to be
unsafe?
$_POST['message'] = "BCC: me@example.com\r\n\r\nlalala";


Totally ineffective.

The $message parameter is not added to the headers. All you would manage to
do is create an email containing the following body:
BCC: me@example.com

lalala


Try reading up on the subject:
<http://uk2.php.net/manual/en/function.mail.php>
<http://www.ietf.org/rfc/rfc0822.txt>

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Nov 22 '05 #14

P: n/a
Philip Ronan wrote:
The $message parameter is not added to the headers.


So naïve! They're all concatenated and passed to the sendmail binary.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Nov 22 '05 #15

P: n/a
"Toby Inkster" wrote:
Philip Ronan wrote:
The $message parameter is not added to the headers.


So nave! They're all concatenated and passed to the sendmail binary.


You really don't have a clue what you're talking about.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Nov 22 '05 #16

P: n/a

Toby Inkster wrote:
Philip Ronan wrote:
The $message parameter is not added to the headers.


So nave! They're all concatenated and passed to the sendmail binary.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact


The message is always preceded by a newline, which delimits it from the
headers.

Nov 22 '05 #17

P: n/a

Philip Ronan wrote:
"Toby Inkster" wrote:
Philip Ronan wrote:
The $message parameter is not added to the headers.


So nave! They're all concatenated and passed to the sendmail binary.


You really don't have a clue what you're talking about.


fine, lets try it: (on a misspelled domain on a server I'm about to
ditch)
http://palmerbodine.com/spamme.php

I cant seem to get it to spam from the message field. I'll leave it up
for a day or so.

--
j

Nov 22 '05 #18

P: n/a
"juglesh" wrote:
I cant seem to get it to spam from the message field.


<smug>
I told you so
</smug>

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

Nov 22 '05 #19

P: n/a
Hello,

on 11/11/2005 09:03 AM Simon said the following:
I was looking at mail injection,
http://securephp.damonkohler.com/ind...mail_Injection

And I was wondering if my mail(...) was safe.

I ask in a form for
1 Name
2 Email address
3 Subject
4 Comment/Message

I then build one message by putting all of the above together.
So even if there was injection, it is all in the body of my message, right?

I then use mail(...) as per normal with my hard coded "To:" and "Subject:"

Is that a fairly safe way?

How should I parse my form to prevent malicious code, (Script? eval?)


Message headers should be encoded with q-encoding (a variant of
quoted-printable encoding for headers). If you do not know how to encode
the messages properly, you may want to try this MIME message class that
can do it for you safely:

http://www.phpclasses.org/mimemessage
--

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
Nov 22 '05 #20

P: n/a

Manuel Lemos wrote:
Hello,

on 11/11/2005 09:03 AM Simon said the following:
I was looking at mail injection,
http://securephp.damonkohler.com/ind...mail_Injection

And I was wondering if my mail(...) was safe.

I ask in a form for
1 Name
2 Email address
3 Subject
4 Comment/Message

I then build one message by putting all of the above together.
So even if there was injection, it is all in the body of my message, right?

I then use mail(...) as per normal with my hard coded "To:" and "Subject:"

Is that a fairly safe way?

How should I parse my form to prevent malicious code, (Script? eval?)


Message headers should be encoded with q-encoding (a variant of
quoted-printable encoding for headers). If you do not know how to encode
the messages properly, you may want to try this MIME message class that
can do it for you safely:

http://www.phpclasses.org/mimemessage


I asked you about mail injection visavis mimemessage class before, but
got an answer that I did not understand 8)

do you need to filter user supplied data prior to sending it thru
mimemessage?

--
juglesh

Nov 22 '05 #21

P: n/a
Hello,

on 11/17/2005 11:55 PM juglesh said the following:
How should I parse my form to prevent malicious code, (Script? eval?)

Message headers should be encoded with q-encoding (a variant of
quoted-printable encoding for headers). If you do not know how to encode
the messages properly, you may want to try this MIME message class that
can do it for you safely:

http://www.phpclasses.org/mimemessage


I asked you about mail injection visavis mimemessage class before, but
got an answer that I did not understand 8)

do you need to filter user supplied data prior to sending it thru
mimemessage?


No, after you pass the data to the class for headers or body parts, it
is encoded properly so certain characters are escaped to remove their
special meaning that could be exploited.

Only some functions that take e-mail address do not do anything with
those address. So, you should validate those addresses with a regular
expression or something more complete like this other class:

http://www.phpclasses.org/emailvalidation
--

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
Nov 22 '05 #22

P: n/a

Manuel Lemos wrote:
Hello,

on 11/17/2005 11:55 PM juglesh said the following:
How should I parse my form to prevent malicious code, (Script? eval?)
Message headers should be encoded with q-encoding (a variant of
quoted-printable encoding for headers). If you do not know how to encode
the messages properly, you may want to try this MIME message class that
can do it for you safely:

http://www.phpclasses.org/mimemessage


I asked you about mail injection visavis mimemessage class before, but
got an answer that I did not understand 8)

do you need to filter user supplied data prior to sending it thru
mimemessage?


No, after you pass the data to the class for headers or body parts, it
is encoded properly so certain characters are escaped to remove their
special meaning that could be exploited.

Only some functions that take e-mail address do not do anything with
those address. So, you should validate those addresses with a regular
expression or something more complete like this other class:

http://www.phpclasses.org/emailvalidation


k, thanx!

Nov 22 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.