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

preventing sendmail injection

P: n/a
looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/

it says that I have to be careful about what I send to the sendmail process
via popen(). Does that also apply to the Subject: line?

(I'm opening a process rather than simply using mail() so that I can set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any dangerous
characters? (IOW, I'm using a whitelist approach.)

Do I need to be concerned about the Subject line regardless?
Aug 31 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
..oO(RJ_32)
>looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/

it says that I have to be careful about what I send to the sendmail process
via popen(). Does that also apply to the Subject: line?
Yes. The Subject is a header, which makes it a possible target for an
injection attack.
>(I'm opening a process rather than simply using mail() so that I can set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any dangerous
characters? (IOW, I'm using a whitelist approach.)
Preventing line breaks in the subject line should be enough.

Micha
Aug 31 '08 #2

P: n/a
RJ_32 wrote:
looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/

it says that I have to be careful about what I send to the sendmail process
via popen(). Does that also apply to the Subject: line?

(I'm opening a process rather than simply using mail() so that I can set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any dangerous
characters? (IOW, I'm using a whitelist approach.)

Do I need to be concerned about the Subject line regardless?
Yes, you do. Anything in the header can be used as a potential SQL
injection point.

The main character you need to worry about is "\r". Most other
characters are OK, but "\r" indicates the end of the current header
entry and the beginning of a new one ("\r\r" signifies end of header).

But I always restrict subjects to printable ASCII characters and spaces
- no tabs, etc., just as a precaution. And that's if I allow the
subject line to pass - most of the time I place the user's subject in
the body of the message and have in the subject line "Message from
example.com" (or similar).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 31 '08 #3

P: n/a
Michael Fesser wrote:
.oO(RJ_32)
>looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/

it says that I have to be careful about what I send to the sendmail process
via popen(). Does that also apply to the Subject: line?

Yes. The Subject is a header, which makes it a possible target for an
injection attack.
>(I'm opening a process rather than simply using mail() so that I can set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any dangerous
characters? (IOW, I'm using a whitelist approach.)

Preventing line breaks in the subject line should be enough.
the author of the page I cited talks about removing the period. Why is that?
>
Micha
Aug 31 '08 #4

P: n/a
RJ_32 wrote:
Michael Fesser wrote:
>.oO(RJ_32)
>>looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/

it says that I have to be careful about what I send to the sendmail process
via popen(). Does that also apply to the Subject: line?
Yes. The Subject is a header, which makes it a possible target for an
injection attack.
>>(I'm opening a process rather than simply using mail() so that I can set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any dangerous
characters? (IOW, I'm using a whitelist approach.)
Preventing line breaks in the subject line should be enough.

the author of the page I cited talks about removing the period. Why is that?
>Micha
No idea. But then I'm not overly impressed with that page. Talk about
making a relatively simple job complicated because < 1% of the user
might need it!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 31 '08 #5

P: n/a
Jerry Stuckle wrote:
RJ_32 wrote:
>looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/
it says that I have to be careful about what I send to the sendmail
process
via popen(). Does that also apply to the Subject: line?

(I'm opening a process rather than simply using mail() so that I can
set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform
textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any
dangerous
characters? (IOW, I'm using a whitelist approach.)

Do I need to be concerned about the Subject line regardless?

Yes, you do. Anything in the header can be used as a potential SQL
injection point.

The main character you need to worry about is "\r". Most other
characters are OK, but "\r" indicates the end of the current header
entry and the beginning of a new one ("\r\r" signifies end of header).
Why the \r instead of a \n? Or both?

My understanding is that \r\n is the recommended ending and just \n
always works for sending mail. That mail can come without \r. My
understanding may be flawed, it has been in the past!

Jeff
>
But I always restrict subjects to printable ASCII characters and spaces
- no tabs, etc., just as a precaution. And that's if I allow the
subject line to pass - most of the time I place the user's subject in
the body of the message and have in the subject line "Message from
example.com" (or similar).
Sep 1 '08 #6

P: n/a
Jerry Stuckle wrote:
RJ_32 wrote:
>looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/
it says that I have to be careful about what I send to the sendmail
process
via popen(). Does that also apply to the Subject: line?

(I'm opening a process rather than simply using mail() so that I can
set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform
textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any
dangerous
characters? (IOW, I'm using a whitelist approach.)

Do I need to be concerned about the Subject line regardless?

Yes, you do. Anything in the header can be used as a potential SQL
injection point.
The OP didn't mention storing anything in a DB. The main security
concern is overwriting headers, probably for spam. Stripping newlines,
as suggested earlier, is sufficient protection.
The main character you need to worry about is "\r". Most other
characters are OK, but "\r" indicates the end of the current header
entry and the beginning of a new one ("\r\r" signifies end of header).
Headers should end with CRLFs, "\r\n". The last header is proceeded by
two CRLFs.
But I always restrict subjects to printable ASCII characters and spaces
- no tabs, etc., just as a precaution. And that's if I allow the
subject line to pass - most of the time I place the user's subject in
the body of the message and have in the subject line "Message from
example.com" (or similar).
--
Curtis
Sep 1 '08 #7

P: n/a
Jeff wrote:
Jerry Stuckle wrote:
>RJ_32 wrote:
>>looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/
it says that I have to be careful about what I send to the sendmail
process
via popen(). Does that also apply to the Subject: line?

(I'm opening a process rather than simply using mail() so that I can
set the
return-path header with sendmail's -f switch and catch bounces.)

My From: and To: are hardcoded and *not* taken from any webform
textfields.

I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);

on the $subject just in case. Is that the correct way to exclude any
dangerous
characters? (IOW, I'm using a whitelist approach.)

Do I need to be concerned about the Subject line regardless?

Yes, you do. Anything in the header can be used as a potential SQL
injection point.

The main character you need to worry about is "\r". Most other
characters are OK, but "\r" indicates the end of the current header
entry and the beginning of a new one ("\r\r" signifies end of header).

Why the \r instead of a \n? Or both?

My understanding is that \r\n is the recommended ending and just \n
always works for sending mail. That mail can come without \r. My
understanding may be flawed, it has been in the past!

Jeff
Because you're not talking about ending - you're looking for invalid
characters.

Some MTA's recognize CR or CRLF, but AFAIK, none recognize just LF as a
line ending character. \r will catch either way, so the request can be
rejected.

Note you should never strip invalid characters - rather, you should
reject the request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Sep 1 '08 #8

P: n/a
On 31 Aug, 22:03, RJ_32 <RJ...@none.comwrote:
Michael Fesser wrote:
.oO(RJ_32)
looking here:
http://www.devarticles.com/c/a/PHP/G...h-PHPs-Mail-Fu...
it says that I have to be careful about what I send to the sendmail process
via popen(). Does that also apply to the Subject: line?
Yes. The Subject is a header, which makes it a possible target for an
injection attack.
(I'm opening a process rather than simply using mail() so that I can set the
return-path header with sendmail's -f switch and catch bounces.)
My From: and To: are hardcoded and *not* taken from any webform textfields.
I'm using:
$i = preg_match_all('/[a-zA-Z0-9_]/', $subject, $arr);
I'd let them uses spaces too, but restrict to 50 chars.
on the $subject just in case. Is that the correct way to exclude any dangerous
characters? (IOW, I'm using a whitelist approach.)
Preventing line breaks in the subject line should be enough.

the author of the page I cited talks about removing the period. Why is that?
IIRC a . on its own indicates then end of a message in SMTP (therefore
subsequent content is the next SMTP command)
C.
Sep 1 '08 #9

P: n/a
Curtis wrote:
>
The OP didn't mention storing anything in a DB.
right, below is what the quoted page said, talking about shell meta
characters. I might have misused the word injection, but I'd meant "injection
of problem characters into the stream piped to sendmail". The writer says that
such can be "disastrous" - I took that to maybe mean that a malicious user
could run shell commands of his choosing somehow.

(And btw, I'm merely taking the page user's supplied name e.g. "John Smith"
and using that in the email's Subject: line.)

"Sendmail Security
When calling the system mail program, we must be careful of what characters we
are sending to it. Because we are opening a Unix pipe, it is possible for
malicious users to enter shell meta characters into form inputs that later are
passed to sendmail. The results can be disastrous.

When creating a form handling script that eventually hands off user-entered
data to the mail program, you must screen user input carefully. Treat all user
input as if it were hostile. Start by removing shell meta-characters from any
input used by sendmail, such as To: and From: inputs, or even the Subject:
input of a feedback form.

Characters that must be removed are the period, for example, if you have an
input for the user name."
The main security
concern is overwriting headers, probably for spam. Stripping newlines,
as suggested earlier, is sufficient protection.
>The main character you need to worry about is "\r". Most other
characters are OK, but "\r" indicates the end of the current header
entry and the beginning of a new one ("\r\r" signifies end of header).

Headers should end with CRLFs, "\r\n". The last header is proceeded by
two CRLFs.
Sep 1 '08 #10

P: n/a
..oO(Jerry Stuckle)
>Because you're not talking about ending - you're looking for invalid
characters.

Some MTA's recognize CR or CRLF, but AFAIK, none recognize just LF as a
line ending character. \r will catch either way, so the request can be
rejected.
I would also watch for the \n. I can remember having problems with PHP's
mail() function and some MTAs, which led to strange results if I used
the correct CRLF to separate my headers. After changing them to LF it
worked ... :(

But meanwhile I use the PHPMailer class, so I don't really have to worry
about such things anymore.

Micha
Sep 1 '08 #11

P: n/a
Michael Fesser wrote:
.oO(Jerry Stuckle)
>Because you're not talking about ending - you're looking for invalid
characters.

Some MTA's recognize CR or CRLF, but AFAIK, none recognize just LF as a
line ending character. \r will catch either way, so the request can be
rejected.

I would also watch for the \n. I can remember having problems with PHP's
mail() function and some MTAs, which led to strange results if I used
the correct CRLF to separate my headers. After changing them to LF it
worked ... :(

But meanwhile I use the PHPMailer class, so I don't really have to worry
about such things anymore.

Micha
Interesting. I've never run into an MTA which just uses lf - but I have
seen some which allow cr only. Thanks for the info, Micha.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Sep 1 '08 #12

P: n/a
RJ_32 wrote:
Curtis wrote:
>The OP didn't mention storing anything in a DB.

right, below is what the quoted page said, talking about shell meta
characters. I might have misused the word injection, but I'd meant "injection
of problem characters into the stream piped to sendmail". The writer says that
such can be "disastrous" - I took that to maybe mean that a malicious user
could run shell commands of his choosing somehow.

(And btw, I'm merely taking the page user's supplied name e.g. "John Smith"
and using that in the email's Subject: line.)

"Sendmail Security
When calling the system mail program, we must be careful of what characters we
are sending to it. Because we are opening a Unix pipe, it is possible for
malicious users to enter shell meta characters into form inputs that later are
passed to sendmail. The results can be disastrous.

When creating a form handling script that eventually hands off user-entered
data to the mail program, you must screen user input carefully. Treat all user
input as if it were hostile. Start by removing shell meta-characters from any
input used by sendmail, such as To: and From: inputs, or even the Subject:
input of a feedback form.

Characters that must be removed are the period, for example, if you have an
input for the user name."
>The main security
concern is overwriting headers, probably for spam. Stripping newlines,
as suggested earlier, is sufficient protection.
>>The main character you need to worry about is "\r". Most other
characters are OK, but "\r" indicates the end of the current header
entry and the beginning of a new one ("\r\r" signifies end of header).
Headers should end with CRLFs, "\r\n". The last header is proceeded by
two CRLFs.
Which is completely asinine. There are many companies which use email
addresses like jo******@example.com. And what if you want a subject
containing something like "St. Elmo's Fire"?

All in all, I'm not very impressed with his comments.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Sep 1 '08 #13

P: n/a
ljb wrote:
RJ***@none.com wrote:
>looking here:
http://www.devarticles.com/c/a/PHP/G...il-Function/2/

it says that I have to be careful about what I send to the sendmail process
via popen(). Does that also apply to the Subject: line?

(I'm opening a process rather than simply using mail() so that I can set the
return-path header with sendmail's -f switch and catch bounces.)

Aside, can't you use the $additional_parameters 4th argument to mail() for
this instead? The manual says:

additional_parameters (optional)

The additional_parameters parameter can be used to pass an additional
parameter to the program configured to use when sending mail using the
sendmail_path configuration setting. For example, this can be used to set
the envelope sender address when using sendmail with the -f sendmail
option.
...
geez, you're right. Thanks. And using mail() is simpler.

I still have the minor problem that the 1st Received: line shows either my
account name (or the nobody user) as the originating server.

I suspect that's why my mail gets tagged as spam by Hotmail.

Sep 2 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.