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] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Jul 2006 16:47:34 +1000 (Australia/ACT)
From: Darren Reed <avalon@...igula.anu.edu.au>
To: dan@...upport.com (Dan Falconer)
Cc: bugtraq@...urityfocus.com
Subject: Re: PHP security (or the lack thereof)



Would you prefer to use something that was designed to be secure
or something that had security applied to it as an afterthought?

As time goes by, if something is designed to be secure then the
number of bugs that impact security should diminish with time
because they are flaws in the implementation (or design.) New
features are designed to fit within the existing security model.

If security is just added on, every time a new feature is added
there is the chance of a security flaw because the security
boundary needs to be extended to suit this new feature and thus
the chances of a bug leading to a security issue are higher.
In addition, bug fixes can also introduce security holes through
unintended interaction consequences.

Since this thread started, how many java related bugs have been
posted to bugtraq vs how many for php?  In keeping with any of
the ratios mentioned?  I think not.

You wanted to compare "bug types" - I'd prefer to see a small
number (and  your "100" was way too large to be realistic) of
bugs in the framework than lots of "in use" bugs.  Why?
Because it tells me that the framework makes it very hard for
the average programmer to make a mistake that has security
implications.

It is time to throw php out and start over with something new.
Something that has security as part of its design.  Something
that learns from all of the security mistakes made with php.
Something that is written with the actual audience that will
use it (security ignorant) in mind, making it easy to develop
dynamic content but using constructs that are aware of how
hostile web interaction can be and that make it quite difficult
to create security flaws.

Darren


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ