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? 13  1938 
..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
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
==================
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
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
==================
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).
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
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
==================
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.
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.
..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
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
==================
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
==================
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Martin Lucas-Smith |
last post by:
Can anyone provide any suggestions/URLs for best-practice approaches to
preventing SQL injection? There seems to be little on the web that I can
find on this.
Martin Lucas-Smith ...
|
by: Robb Meade |
last post by:
Hi all,
A recent project that I had finished and went live with no apparant
problems.
My client received an email from a user who mentioned that by accident they
had been typing (over the...
|
by: aaj |
last post by:
Hi all
We had a small problem when an ASP web page had a missing 'where' statement
and updated all the records in the table. Luckily we could retrieve all the
data from the backups.
How do...
|
by: www.douglassdavis.com |
last post by:
I have an idea for preventing sql injection attacks, however it would
have to be implemented by the database vendor. Let me know if I am on
the right track, this totally off base, or already...
|
by: Shelly |
last post by:
I submitted this to comp.mail.sendmail, but maybe someone here can help me
as well.
OK, this has most likely been asked and answered several times, but I am
still confused after searching. Here...
|
by: bregent |
last post by:
I've seen plenty of articles and utilities for preventing form injections for
ASP.NET, but not too much for classic ASP. Are there any good input validation
scripts that you use to avoid form...
|
by: Kevin Audleman |
last post by:
My site has come under attack from sql injections. I thought I had
things handled by replacing all single quotes with two single quotes,
aka
Replace(inputString, "'", "''")
Alas, clever...
|
by: jcage |
last post by:
Is there any tutorials online for sending email through forms? I can
send an email as well as write to my MySQL database from home with the
following code but not at work. I think there might be...
|
by: digitaldiva |
last post by:
Hi I am new here and once upon a time I worked with Perl, now I am trying again and need some help:
I wrote a Perl script a few years ago that opened an order entry TXT file and sent each...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
