bugtraq - Re: Securing PHP or finding PHP alternatives

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b271040a0607181435l27d83075i2989ee63c1c1e12a@mail.gmail.com>
Date: Tue, 18 Jul 2006 16:35:20 -0500
From: "Michael Cordover" <michael.cordover@...il.com>
To: bugtraq@...urityfocus.com, "Crispin Cowan" <crispin@...ell.com>,
	"Sheryl Coppenger" <gubydala@....com>
Subject: Re: Securing PHP or finding PHP alternatives

On 7/11/06, Sheryl Coppenger <gubydala@....com> wrote:
> Crispin Cowan wrote:
> > Gezim Hoxha wrote:
> >> 1.) If I have to write PHP, how do I write secure PHP? Give me a number
> >> of ensures that I can follow and check-mark each and live a happy
> >> life--for the most part.
> >>
> > Program defensively:
> [snip]
> > Test your system:
> [snip]
>
> > Wrap it in AppArmor http://en.opensuse.org/AppArmor for when you screw
> > up ^W^W don't do all the above perfectly.
>
> But that's only available if you're using Suse, right?  What about
> hardened PHP, modsecurity, putting Apache in a chroot jail, that sort of
> thing?
>

Yeah, this is an important one.  Use security on multiple levels.
Code your stuff so it's invulnerable, but make it so even if it isn't,
the site doesn't collapse.  Put your administrative settings in a
different database, with different permissions, to your user stuff -
if possible using the administrator's password as the (my|pg)SQL user
password, so sql injections don't kill the site, just userland data.
Don't have write access where it's unnecessary, or read for that
matter: set permissions properly.  Store SQL connections strings and
other sensitive information in a file to be require_once()d from
outside the web-accessible directory, just in case php suddenly
becomes uninstalled.  Use php_flag and php_value in .htaccess, in case
your host changes php.ini without telling you.  Code so you don't rely
on anything within php.ini.  Initialise all variables before you use
them, access user input all within the $_GET, $_POST, $_COOKIE, $_FILE
superglobals.

Also configure your system properly.  Keep up to date!  Use hardened
php, modsecurity and apache in a jail for a start.  Give your php user
limited access only to those files it needs access to.  And then it
goes lower - secure your kernel.  use ACLs.

The key point here?  There are more entranceways to your server than
you think.  Block them all.  Secure your system in every place
possible.  Use encryption.  Never, ever, ever rely on a user, or
administrator, for security - have everything coded securely.  A good
administrator will keep it that way and add their own restrictions...
but a bad one might not.  Also don't be slack once you get into the
admin area.  just because it's only meant to be accessed by someone
with a vested interest in the site, that doesn't mean that's how it'll
happen.  Some stupid admin will use "d34db33f" as a password and think
they're funny - don't let this compromise the site.  And at all costs,
for the sake of humanity, make it so a site compromise can't turn your
server upside down, can't make your server a spamer, and can't modify
anything on the server other than that specific site.

And that is my rant for today.

Michael

-- 
http://mine.mjec.net/