Web server security - Security

This is a discussion on Web server security - 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 ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: Web server security

  1. 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


  2. Re: Web Server Security

    > 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.


    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
    > 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.


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

    Also, from another post:

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


















  3. Re: Web server security

    Moe Trin wrote:

    > PHP is _so_ easy to abuse.


    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 ...

    >> 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?


    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 syl@alcor.concordia.ca

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

  4. Re: Web server security

    Sylvain Robitaille wrote:

    > Moe Trin wrote:
    >
    >> PHP is _so_ easy to abuse.

    >
    > 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.


    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



  5. Re: Web server security

    On Sat, 2 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
    , Sylvain Robitaille wrote:

    >Moe Trin wrote:
    >
    >> PHP is _so_ easy to abuse.

    >
    >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.


    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.

    > PHP itself is just a language interpretter.


    [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

  6. Re: Web server security

    Moe Trin wrote:

    > The problem I see is that most PHP is poorly written.


    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.

    > [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.


    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 syl@alcor.concordia.ca

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

  7. Re: Web server security

    On 2007-06-02, Moe Trin wrote:
    >
    > 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.


    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

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


  8. Re: Web server security

    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


  9. Re: Web server security

    Shidony wrote:

    > @ 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.


    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.

    > 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.


    I have red-flags popping up all over the place in my mind! ;-)

    > 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?


    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.

    > I must admit that at times I have also copied code found on the web.
    > I shall be more careful now.


    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.

    > I have strenghtened the PHP forms a little by adding email validation
    > code.


    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).

    > 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.


    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 syl@alcor.concordia.ca

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

  10. Re: Web server security

    On Mon, 4 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
    , Sylvain Robitaille wrote:

    >Shidony wrote:


    >> @ 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.

    >
    >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.


    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'.

    >> 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.

    >
    >I have red-flags popping up all over the place in my mind! ;-)


    Regrettably, same here

    >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.


    or hit their web site (http://www.oreilly.com/ 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.

    >The latest Linux Journal has a rather timely and informative article on
    >exactly this.


    If you are not a subscriber, http://www.kinuxjournal.com - another item
    that may be of interest is their archive CD (issues 1 to 152, which is
    3/94 to 12/06) at http://www.kinuxjournal.com/ArchiveCD. 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

  11. Re: Web server security

    Moe Trin wrote:

    > My wife absolutely prohibits me from entering a book store unescorted.


    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 syl@alcor.concordia.ca

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

  12. Re: Web server security

    On Tue, 5 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
    , Sylvain Robitaille wrote:

    >Moe Trin wrote:
    >
    >> My wife absolutely prohibits me from entering a book store unescorted.

    >
    >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! :-)


    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

  13. Re: Web server security

    On 2007-06-05, Sylvain Robitaille wrotey all complicatey:
    > Moe Trin wrote:
    >
    >> My wife absolutely prohibits me from entering a book store unescorted.

    >
    > 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! :-)


    Annnnnd miss that point !

    Regards,

    BH.

  14. Re: Web server security

    Moe Trin wrote:
    > My wife absolutely prohibits me from entering a book store unescorted.
    >


    You could always subscribe to the Safari Network (http://safari.oreilly.com/)
    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.

  15. Re: Web server security

    On 08 Jun 2007, in the Usenet newsgroup comp.os.linux.security, in article
    <4669ad6a$0$9956$4c368faf@roadrunner.com>, Melissa wrote:

    >Moe Trin wrote:


    >> My wife absolutely prohibits me from entering a book store unescorted.

    >
    >You could always subscribe to the Safari Network
    >(http://safari.oreilly.com/)and not have to enter a bookstore for a
    >variety of technical books.


    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.

    >The university at which I work has a limited subscription and it is
    >quite nice if you don't mind reading books online.


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

    Old guy

  16. Re: Web server security

    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.

    mike@surgeontech.com


+ Reply to Thread