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 for Android: free password hash cracker in your pocket

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

Date: Mon, 17 Jul 2006 21:58:15 -0700
From: Crispin Cowan <crispin@...ell.com>
To: SkyFlash <webmaster@...kquest.de>
Cc: bugtraq@...urityfocus.com
Subject: Re: Securing PHP or finding PHP alternatives

SkyFlash wrote:
>>> 2.) From a security standpoint what is a better, open-source
>>> replacement
>>> to PHP?
>>>  
>> Ruby, Python, Java, C#, all of which are type safe, and therefore much
>> more secure. All have open source implementations, including C#
>> http://www.mono-project.com/Main_Page
>>
> Being type safe does not mean you can't screw up when validating user
> input.
True; it does not block all kinds of bugs, just some broad classes of them.

> Also, PHP can be type safe, if you choose to use it that way.
You can write secure programs in any programming language if you are
sufficiently disciplined. But that fails to distinguish between
programming languages, some of which are more error prone than others.

> None of these languages will fix badly written code for you, so they
> aren't more safe. You don't need to secure the specific programming
> language, you need to secure your own lazy ass producing bad code.
> Also, there is no better, open source replacement for PHP.
Yes they are more safe, precisely because they *do* block some broad
classes of vulnerabilities, such as buffer overflows and integer
underflows (assuming you haven't disabled array bounds checking). What
the aren't is *totally* safe, but no one ever said they were. In fact,
when I raised this issue of Turing-completeness in this thread, that was
exactly my point: no Turing-complete language can ever be totally safe.

> If you write code, it will have bugs, and it will have security holes,
> so live with it. No matter how many graphs you draw and talk about
> it... in the end, it will still have bugs, and you won't be able to
> quantify them.
Where do you get this assertion that vulnerabilities cannot be quantified?

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unaticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes