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