On Wed, 12 Feb 2003, Jason Wong wrote:
> On Wednesday 12 February 2003 07:46, Chris Wesley wrote:
> >   You access an FTP server with a user name and a password to retrieve a
> >   file via PHP FTP.  The user name and password is the same that grants
> >   you access to your hosting providers server.  (People do this
> >   v.frequently.  Most people have trouble remembering one
> >   username/password, so they make the dangerous choice to use one
> >   username/password over and over again.)  A malicious individual sniffs
> >   your username and password while you transfer a file via FTP from to you
> >   hosting provider.  Once the individual has his way with your FTP site
> >   using your credentials, (s)he does the obvious next step ... attempts to
> >   use the same credentials to gain access to your hosting providers
> >   server.
>
> Even they they are not clueless and they were trying to say what you're
> saying, it is still a very poor argument.

Why?  What's a better argument?  It's certainly just a piece of a much
larger argument, but avoiding a full-fledged lecture outside the immediate
context of the original question (and trying to keep it related to PHP
somehow) makes it brief.

> So they allow incoming FTP (presumably that's what people use to upload their
> site) but disallow outgoing FTP because someone might sniff the
> username/password? Does it make sense?
>
> [snip]
>
> > Ws-ftp uses plain-text authentication.  The FTP extension to PHP uses
> > plain-text authentication.  (Neither has a choice, since FTP is a
> > plain-text protocol.)  They both present security risks for the same
> > reason.
>
> A security risk in that someone might be able to get your login credentials
> and upload stuff to your FTP space, BUT not necessarily a security risk to
> the server itself. Modern FTP servers support virtual users and chroot so the
> risk of server compromise is minimised.

Not so.  Nevermind gaining access to the hosting server via FTP.  With
stolen credentials, one might log into the server via SSH, or gain access
to other services on the box with the stolen credentials.  It doesn't
matter what modern service you have running ... once you've stolen the
keys, you're in, and you can do /something/ you're not supposed to do.

I've seen chrooted home directories in exactly one place.  You'll almost
never find them in a shared hosting environment.  Most likely, there are
quotas.  Even so, the risk of having unauthorized users on your server(s)
is not acceptable under any circumstances, especially through one avenue
you know you can shut down.  With the quotas in todays shared hosting
offerings, there's enough space to distribute/run/launch a myriad of
malicious software, or simply replace the account owner's content with
warez for a short time.  The risks range from a minor pain in the ass to
becoming a platform for launching [D]DoS attacks, worms, or viruses.

On the Internet, risk is risk, big or small, and none if good.  Do away
with as much of it as you can.

        ~Chris




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to