full-disclosure - AW: AW: securing php

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>] [day] [month] [year] [list]

Message-ID: <DF79BE12AF8DD344B107D0D03621E5750ED9C7@kermit.corp.hansenet.com>
From: vogt at hansenet.com (vogt@...senet.com)
Subject: AW: AW: securing php

> > You an enable PHP's "Safe Mode", which goes a long way to
> > closing these holes, but it's not a 100% solution.
> 
> PHP uses many libraries which were not designed to cope with malicious
> input from the application.  That's why PHP Safe Mode is unsafe *by*
> *design*.

Yes, but you have two different sets of problems here:

a) PHP by default has the same access to the system as Apache does,
   which is way too much.
   Safe Mode does (mostly) solve this problem

b) Input verification and all other problems of exploiting PHP
   scripts, just as you have in any other language
   Safe Mode does nothing against these, though it can help to
   contain an exploit.

As I said: It's not a 100% solution, but that is not an excuse for
not using it and at least get what safety it offers.

Tom Vogt