PHP and insecurity

[jeff.williams at aspectsecurity.com (Jeff Williams)]

FYI -- Andrew van der Stock (OWASP Guide project lead) has posted a
challenge (http://www.greebo.net/?p=320) to the PHP community -- get secure
or become irrelevant. The tradeoffs being discussed between power,
simplicity, and security are relevant to all environments. In fact, anyone
designing an API for anything should read the discussion
(http://shiflett.org/archive/185) and think about whether it encourages
secure software. 

 

"After writing PHP forum software for three years now, I've come to the
conclusion that it is basically impossible for normal programmers to write
secure PHP code. It takes far too much effort. PHP needs a proper security
architecture, and support for newbie programmers. PHP's raison d'etre is
that it is simple to pick up and make it do something useful. There needs to
be a major push by the PHP Development team to take this advantage, and make
it safe for the likely level of programmers - newbies. Newbies have zero
chance of writing secure software unless their language is safe. 

... 

There are so many ways to break PHP that it is impossible for even
experienced security professionals like me to code in it securely all the
time. There are nearly 4000 function calls, and many of them have unintended
consequences or have been inappropriately extended by something else. At
every turn, the PHP Development Team have made truly terrible "security"
choices: register_globals, magic_quotes_gpc (and friends), PHP wrappers,
safe mode, output, XML, LDAP, and SQL interfaces that intermingle data and
query elements, which by their very nature are impossible to protect against
injection attacks. All of these are broken. They are disjunct and have no
security model. Some of the features, like PHP wrappers, are not well
documented, and are a clear and present danger to PHP scripts and worse,
they do not obey the weak "safe" mode restrictions. I bet few PHP coders are
aware of them, let alone their security impacts. 

... 

PHP must now mature and take on a proper security architecture, an over
arching security model which prevents or limits attack surface area until
the application explicitly asks for it. There can be no other way. If you
look at Bugtraq, every day, 10-50 PHP applications are broken mercilessly.
This cannot continue. Hosters cannot pay the price for the PHP development
team's lack of security expertise."

 

--Jeff

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060125/ed67e5d1/attachment.html