Re: Scripting Languages and Secure Coding

[Jeremy Thibeaux <jeremy.thibeaux () lucidfactory com>]

I would look at this differently.  If PHP (or some
other scripting language) solves most of the problems
you need to solve when writing Web applications
securely, then it makes sense to reuse this code
rather than reinventing the wheel and making oneself
vulnerable to one's own mistakes (not to mention C
giving you much more liberty to create problems than
PHP).  Like with C, it seems that good coding
practices will lead to secure PHP, but less code is
required using PHP than required using C.  

I am not aware of any buffer overload problems with
PHP >=4.2.2, but I did find that there were some fixes
required from previous versions (file upload and
wordwrap exposed problems).  When going to CERT, you
will find several notices most of which cover the same
"file upload" problem.  If you are using an old
version of PHP and also supporting file uploads, you
ought to upgrade or apply the patches without
hesitation.

The reason why you won't see security notices for C
(or perhaps Perl), is that they leave it entirely up
to you to make your own mistakes.  One will likely
find security problems in reusable C or Perl
components if they end up as abundantly tested as PHP.
 Not to mention that PHP includes a ridiculous amount
of functionality.

If there are KNOWN vulnerabilities with PHP 4.3 that
are not eliminated by proper validation of user input,
this would be a great place to point them out.

Jeremy Thibeaux
Lucid Factory, inc.