|
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 |
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
