Web server security

Hi guys & gals,

Not sure whether to post this topic here or on the Linux-Admin
forums. Here goes!

I have various pages on our company website whereby a user can
populate their information and email to us. Recently I have noticed a
lot of emails with similar data formatting as the web forms and it
appears to be coming from our web server. However, on some emails the
subject is different to what is hard coded in PHP.

So my question is, what security measures should I take to ensure that
only legitimate emails sent through the web forms come through and not
the ones filled out by bots? I highly doubt that a bot would be using
our forms since all the coding is in PHP and not visible to users.
That only leaves the possibility of insecure SMTP.

Looking forward to your input!

BTW our web host is a Fedora Core 2 server with Sendmail 8.12.11 and
Apache 2.0.51 installed on it. I'll be happy to provide more details
if necessary.

P.S: Can anybody provide a link of best practices for securing linux
web/mail/dns servers that have a public presence?

Cheers,
Shid

> I highly doubt that a bot would be using[color=blue]
> our forms since all the coding is in PHP and not visible to users.
> That only leaves the possibility of insecure SMTP.[/color]

Form spammers LOVE php forms, since a very high percentage of them in "free
script repositories" are faulty and allow spammers to do what is called
"injection". Perl scripts run a not too distant second. Here is some
relevant information for you :

From a post from about 28.8.2006[color=blue]
> The spammer injects the characters '\n' and '\r'*(end of line and carriage
> return) in an explotiable web form* and then adds "bcc:" followed by a
> long list of spamees. (If you start getting "bounces" then that is what
> has happened). If he is allowed to do this several times, you end up on a
> set of email blocklists from which removal is damn near impossible. At
> that point your provider either disconnects you or puts a contract out on
> you (depending on where you live) or both.
>
> Spammers aren't usually the brightest bulbs in the box, so they like this
> technique because it requires virtually no talent and can be run from a
> script. Also, about a 10-15% of the forms I see are exploitable, despite
> the stellar credentials of some of the webmasters owning then. It's just
> that easy to overlook.
>
> Verify that there is a control character filter on you web form or that
> the mail handler you use does not accept the "bcc" statement.*Either one
> will foil his attempts.*
> To filter:
> with php use
> "if(egregi("\r",[field]) || egregi("\n",[field])) die("No Spam From Me!") **
> with perl use regular expression matching
> with C and C++ use regexec and regcomp.
> to trap these characters.[/color]

The author failed to mention that sendmail and postfix happily accept bcc:
statements.

Also, from another post:
[color=blue]
> Some more techical information is on Damon Kohler's wiki at
> [url]http://www.securephpwiki.com/index.php/Email_Injection[/url]. Even if you
> are not too technical, it is worth a read to see what you are up against.[/color]

Moe Trin wrote:
[color=blue]
> PHP is _so_ easy to abuse.[/color]

I know I'm being pedantic, but I think there is an important distinction
to be made:

Poorly written PHP code is an easy target for abuse. PHP itself is
just a language interpretter.


To the OP ...
[color=blue][color=green]
>> So my question is, what security measures should I take to ensure that
>> only legitimate emails sent through the web forms come through and not
>> the ones filled out by bots?[/color][/color]

You've gotten some good advice already, that will certainly be worth the
time you take to research and learn more about. In your travels, be
sure to examine the idea of chroot-ing the web server. I agree with
previous assessments that most likely you have a poorly written script
that is being abused, as many others have been in the past (read: same
old problems in new attire).

My recommendation is that you disable any mailing functionality in your
PHP scripts (perhaps have it simply write user input to a local file
which is checked daily by a human) until you have a better grasp of how
to write the script so it can't be abused as easily. I imagine that's
not the sort of advice you were hoping for, but it's the best I can offer.

--
----------------------------------------------------------------------
Sylvain Robitaille [email]syl@alcor.concordia.ca[/email]

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Sylvain Robitaille wrote:
[color=blue]
> Moe Trin wrote:
>[color=green]
>> PHP is _so_ easy to abuse.[/color]
>
> I know I'm being pedantic, but I think there is an important distinction
> to be made:
>
> Poorly written PHP code is an easy target for abuse. PHP itself is
> just a language interpretter.[/color]

I would add that a poorly/well configured PHP subsystem makes a difference
too. php.ini does have a few knobs that can help mitigate against coding
errors.

But in general, I agree. PHP attracts the good and the useless, so there is
a high proportion of crap code out there because a lot of not-very-good
programmers are generating it.

IMO one tends to find a lower ratio of bad perl code (but it's there)
because perl looks weird, and is perhaps considered "old-skool" and
unfashionable and those attributes put people off.

Cheers

Tim

On Sat, 2 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
<slrnf61okb.j5h.syl@alcor.concordia.ca>, Sylvain Robitaille wrote:
[color=blue]
>Moe Trin wrote:
>[color=green]
>> PHP is _so_ easy to abuse.[/color]
>
>I know I'm being pedantic, but I think there is an important distinction
>to be made:
>
> Poorly written PHP code is an easy target for abuse.[/color]

The problem I see is that most PHP is poorly written. People don't want
to take the time to learn the language, and copy the horrendous stuff
that can be found everywhere, without understanding what it's doing, and
how some relatively simple coding problems can be eliminated.
[color=blue]
> PHP itself is just a language interpretter.[/color]

[compton ~]$ ls /var/spool/news/news/mailing/unix/bugtraq/* | wc -l
442
[compton ~]$ grep -l PHP /var/spool/news/news/mailing/unix/bugtraq/* | wc -l
46
[compton ~]$ ^l PHP^liw perl
grep -liw perl /var/spool/news/news/mailing/unix/bugtraq/* | wc -l
10
[compton ~]$ ^perl^ruby
grep -liw ruby /var/spool/news/news/mailing/unix/bugtraq/* | wc -l
4
[compton ~]$ ^ruby^python
grep -liw python /var/spool/news/news/mailing/unix/bugtraq/* | wc -l
10
[compton ~]$

Those other languages were grabbed at ransom. Many of the PHP articles
reflect problems with supplied crap that was written in PHP, rather than
fundamental problems with the language or interpreters.

("mailing.unix.bugtraq" is one of a number of mirrors of the Bugtraq
mailing list carried by news servers. This mirror happens to be from
csie.nctu.edu.tw, but the numbers from the muc.lists.bugtraq group which
is the mirror from "Newsgate at muc.de e.V." are virtually identical. The
442 articles is about a month of the list.)

Old guy

Moe Trin wrote:
[color=blue]
> The problem I see is that most PHP is poorly written.[/color]

Agreed, but that's not PHP's fault. Perl had that problem too at one
time, back when CGI was all the rage, and Perl was _the_ language CGI
scripts were available in.
[color=blue]
> [compton ~]$ ls /var/spool/news/news/mailing/unix/bugtraq/* | wc -l
> 442
> [compton ~]$ grep -l PHP /var/spool/news/news/mailing/unix/bugtraq/* | wc -l
> 46
> ...
> Many of the PHP articles reflect problems with supplied crap that was
> written in PHP, rather than fundamental problems with the language or
> interpreters.[/color]

My point exactly. You're showing that a little more than 10% of the
issues in recent discussion on Bugtraq relate to PHP or PHP scripts
(scripts, mostly). Too many people who don't know how to program
relying on too many scripts written by other people who also don't know
how to program. We've seen this all before already, and we'll likely
see it again with the next _big_ trendy language.

--
----------------------------------------------------------------------
Sylvain Robitaille [email]syl@alcor.concordia.ca[/email]

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On 2007-06-02, Moe Trin <ibuprofin@painkiller.example.tld> wrote:[color=blue]
>
> The problem I see is that most PHP is poorly written. People don't want
> to take the time to learn the language, and copy the horrendous stuff
> that can be found everywhere, without understanding what it's doing, and
> how some relatively simple coding problems can be eliminated.[/color]

Well, the solution for the OP is to do a careful code review to make
sure the PHP code he has isn't horrendous.

--keith

--
[email]kkeller-usenet@wombat.san-francisco.ca.us[/email]
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Thank you all for your insight into PHP scripting.

@ Moe: I agree with you, it is time for an update. FC2 is what I
faced when I began my tenure as a Systems Admin about a year ago. I
will recommend the same at our next meeting.

@ Sylvain: Disabling email functionality is not an option I can pursue
at this stage. These emails are a good source of leads for our Sales
Department.

As far as PHP scripting goes, our website was developed by a local Web
Development company. As such I had no control over the scripting
itself. Now I find myself going through all their coding in order to
eliminate spam hacking threats. By no means do I claim to be a PHP
expert, which is why I would like to learn more about the language.
What would you recommend as a good learning resource? I must admit
that at times I have also copied code found on the web. I shall be
more careful now.

I have strenghtened the PHP forms a little by adding email validation
code. This should minimise (possibly eliminate ^_^) email address
injection problems. Chroot-int the web server sounds like an
interesting concept. I did touch on it recently, but am reluctant to
change things until I fully research the subject.

All your opinions are greatly appreciated!!!!

Shid

Shidony wrote:
[color=blue]
> @ Sylvain: Disabling email functionality is not an option I can pursue
> at this stage. These emails are a good source of leads for our Sales
> Department.[/color]

One option might be to change the script(s) so that regardless of what it
receives as input, it will send a message only to "sales@yourcompany.com",
with all user input placed in the message body. If the user input is
removed from the equation of the message being sent (either to determine
recipients, or to set up sender addresses and so on), and used only as
text input for a message to a hard-coded recipient, you'll be able to
continue getting the benefit, but significantly reduce the opportunities
for abuse.
[color=blue]
> As far as PHP scripting goes, our website was developed by a local Web
> Development company. As such I had no control over the scripting
> itself.[/color]

I have red-flags popping up all over the place in my mind! ;-)
[color=blue]
> By no means do I claim to be a PHP expert, which is why I would like
> to learn more about the language. What would you recommend as a good
> learning resource?[/color]

As I've mentioned in a previous message, most of the problems that exist
with poor PHP scripting have already been seen in other forms (mostly
with poorly-written PERL scripts that were similarly being abused some
years ago). To understand the threats, spend some time going through
the Bugtraq archives, focussing primarily on PERL and PHP scripts for
interaction via a web interface.

You'll find many examples that come down to a small set of similar
errors, mostly based around not verifying or sanitizing user input.

To understand the (proposed) solutions (in the context of your needs),
start by examining what others have done and/or recommended. Combine
that with your improving knowledge of the language and its interpretter.

For language (and application) references, I tend to rely on two sources
primarily: the main web sites associated with each (be it Perl or PHP in
this case, or other applications I might need to manage in other cases),
and the O'Reilly books at my local bookstore. I commute to/from work
by commuter train, so I have lots of time to read. :-)

I tend to consider third-party information very carefully before taking
action based on it. Samples from websites, publications, and so on, are
usually treated as that: samples, rather than complete code. I end up
writing a lot of stuff myself that might already have been done by someone
else (and I could have used), but in so doing, I know that what we have
will do exactly as we need (and nothing more), and if the needs change
(as they often do), I know exactly where to apply changes to reflect
the new needs.
[color=blue]
> I must admit that at times I have also copied code found on the web.
> I shall be more careful now.[/color]

Apply liberal amounts of "professional paranoia". It will take you
longer than just locating a script that _claims_ to do what you need,
but in the end you'll be saving yourself a lot of aggravation and
additional work of cleaning up after incidents like you're presently
doing.
[color=blue]
> I have strenghtened the PHP forms a little by adding email validation
> code.[/color]

The latest Linux Journal has a rather timely and informative article on
exactly this. Note, however, that in the case you're describing, it
might be sufficient (as I suggest above) to simply hard-code the
recipient address, and use the sender's address simply as plain text in
the body of the message, where it won't be interpretted at any point as
an email address (until it is used as such by a human, who would be able
to identify an attempt at abuse).
[color=blue]
> Chroot-int the web server sounds like an interesting concept. I did
> touch on it recently, but am reluctant to change things until I fully
> research the subject.[/color]

Understood, and I agree that it's a good idea to proceed cautiously.
I don't manage a single system with a web server that isn't chrooted
(where the system has a web server at all, that is). It tends to increase
the time it takes me to setup a new application on any given web server,
but it's also saved me a lot of trouble.

Note that the chroot is just a container for problems: it won't
eliminate possible abuse, at least not by itself, but it *does* contain
the damage that is possible, based on what is made available inside the
chroot.

I hope I've helped ...

--
----------------------------------------------------------------------
Sylvain Robitaille [email]syl@alcor.concordia.ca[/email]

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Mon, 4 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
<slrnf6746v.ctu0.syl@alcor.concordia.ca>, Sylvain Robitaille wrote:
[color=blue]
>Shidony wrote:[/color]
[color=blue][color=green]
>> @ Sylvain: Disabling email functionality is not an option I can pursue
>> at this stage. These emails are a good source of leads for our Sales
>> Department.[/color]
>
>One option might be to change the script(s) so that regardless of what it
>receives as input, it will send a message only to "sales@yourcompany.com",
>with all user input placed in the message body.[/color]

Agreed one hundred ten percent. The mail functionality is something that
should be restricted such that no matter what happens, mail is ONLY sent
to a screening account (such as 'webleads@yourcompany.com' so that the
"sales@' account isn't buried under eleventy-zillion offers of blue pills
and enlarging creames etc.). One further step that can be taken is to
set the firewalls such that the web server can ONLY send mail locally,
which means blocking 'source=web-server: destination=any:25 or
destination=any:587'.
[color=blue][color=green]
>> As far as PHP scripting goes, our website was developed by a local Web
>> Development company. As such I had no control over the scripting
>> itself.[/color]
>
>I have red-flags popping up all over the place in my mind! ;-)[/color]

Regrettably, same here
[color=blue]
>For language (and application) references, I tend to rely on two sources
>primarily: the main web sites associated with each (be it Perl or PHP in
>this case, or other applications I might need to manage in other cases),
>and the O'Reilly books at my local bookstore.[/color]

or hit their web site ([url]http://www.oreilly.com/[/url] From last year, I see

[_] Build Your Own Database Driven Website Using PHP and MySQL, Third
Edition Oct 2004 $39.95 Download examples

[_] Essential PHP Security Oct 2005 $29.95 Read it on online with
Safari View a sample

[_] Learning PHP 5 Jun 2004 $29.95 Read it on online with Safari View
a sample Download examples

[_] Learning PHP and MySQL May 2006 $29.99

[_] No Nonsense XML Web Development With PHP Jul 2005 $39.95

[_] Object Oriented PHP Apr 2006 $39.95

[_] PHP Anthology Dec 2004 $39.95 Download examples

[_] PHP Black Book Oct 2001 $59.99

[_] PHP Cookbook Nov 2002 $39.95 Read it on online with Safari View a
sample Download examples

[_] PHP Hacks Dec 2005 $29.95 Read it on online with Safari View a
sample Download examples

[_] PHP in a Nutshell Oct 2005 $29.95 Read it on online with Safari
View a sample

[_] PHP Pocket Reference, Second Edition Nov 2002 $9.95 Read it on
online with Safari

[_] PHP Security Collection - PDF Apr 2004 $5.95

[_] PHPUnit Pocket Guide Sep 2005 $9.95 Read it on online with Safari

[_] Programming PHP Mar 2002 $39.95 Read it on online with Safari View
a sample Download examples

[_] Upgrading to PHP 5 Jul 2004 $29.95 Read it on online with Safari
View a sample Download examples

[_] Web Database Applications with PHP and MySQL, Second Edition May
2004 $44.95 Read it on online with Safari View a sample Download
examples

[_] Wicked Cool PHP Jun 2006 $29.95

My wife absolutely prohibits me from entering a book store unescorted.
[color=blue]
>The latest Linux Journal has a rather timely and informative article on
>exactly this.[/color]

If you are not a subscriber, [url]http://www.kinuxjournal.com[/url] - another item
that may be of interest is their archive CD (issues 1 to 152, which is
3/94 to 12/06) at [url]http://www.kinuxjournal.com/ArchiveCD[/url]. There are
other magazines that are available - perhaps 'aus.computers.linux' might
be a good place to check for local flavor. I know a couple of really
sharp people monitor that group.

Old guy

Moe Trin wrote:
[color=blue]
> My wife absolutely prohibits me from entering a book store unescorted.[/color]

LOL! Mine's just as bad as I am, so it's really a question of who has
the strongest will-power at any given moment to walk *past* the
bookstore! :-)

--
----------------------------------------------------------------------
Sylvain Robitaille [email]syl@alcor.concordia.ca[/email]

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Tue, 5 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
<slrnf69sj5.4npk.syl@alcor.concordia.ca>, Sylvain Robitaille wrote:
[color=blue]
>Moe Trin wrote:
>[color=green]
>> My wife absolutely prohibits me from entering a book store unescorted.[/color]
>
>LOL! Mine's just as bad as I am, so it's really a question of who has
>the strongest will-power at any given moment to walk *past* the
>bookstore! :-)[/color]

Mine isn't /quite/ as bad as I, but she may have a point because I'm
running out of shelf space - and that's with two extra bedrooms with
wall-to-wall book cases, and books that I don't find interesting go to
the second hand book store rather than wasting shelf space. But I _do_
read the books - last I counted, there were less than a hundred books
on the "to be read" shelves.

Old guy

On 2007-06-05, Sylvain Robitaille <syl@alcor.concordia.ca> wrotey all complicatey:[color=blue]
> Moe Trin wrote:
>[color=green]
>> My wife absolutely prohibits me from entering a book store unescorted.[/color]
>
> LOL! Mine's just as bad as I am, so it's really a question of who has
> the strongest will-power at any given moment to walk *past* the
> bookstore! :-)[/color]

Annnnnd miss that point !

Regards,

BH.

Moe Trin <ibuprofin@painkiller.example.tld> wrote:[color=blue]
> My wife absolutely prohibits me from entering a book store unescorted.
>[/color]

You could always subscribe to the Safari Network ([url]http://safari.oreilly.com/[/url])
and not have to enter a bookstore for a variety of technical books. The
university at which I work has a limited subscription and it is quite nice
if you don't mind reading books online. I wish they had kept the unlimited
subscription ($440/yr on special right now, $550/yr otherwise) because it
had access to all the good books. At their current price for the unlimited
subscription, that works out to less than $40 a month, which would be
cheaper than buying 1 or 2 print books per month.

On 08 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
<4669ad6a$0$9956$4c368faf@roadrunner.com>, Melissa wrote:
[color=blue]
>Moe Trin <ibuprofin@painkiller.example.tld> wrote:[/color]
[color=blue][color=green]
>> My wife absolutely prohibits me from entering a book store unescorted.[/color]
>
>You could always subscribe to the Safari Network
>([url]http://safari.oreilly.com/)and[/url] not have to enter a bookstore for a
>variety of technical books.[/color]

Technical books - especially from O'Reilly - aren't a really big problem,
as I get nearly all of those at work. At home, I there is only about one
bookcase full of them, plus the dozen or so on the desk between the
monitors. The problem lies with - I guess the term would be "recreational
reading". I'm a history buff, and have literally two rooms full of book
cases which are full of books. Add the map collection, and her collection
of fiction, and we're starting to run out of book shelf space.
[color=blue]
>The university at which I work has a limited subscription and it is
>quite nice if you don't mind reading books online.[/color]

For technical books, I actually prefer this. On-line _usually_ means
more up to date, and being able to grep for something.

Old guy

Modify your php script to print out the POST data to a log file. Look
at the log file. You'll see how he's tricking your PHP into sending
spam. Then modify your PHP to "cleanse" the POSTed form data.

[email]mike@surgeontech.com[/email]