Re: Scripting Languages and Secure Coding + code

["David A. Wheeler" <dwheeler () ida org>]

It's certainly possible to use scripting languages to implement
secure software.  However, different languages have different strengths.
I wouldn't be surprised if there are some languages you CAN'T write
secure software in.  There are certainly some languages where it's
harder than others.  Some languages have "sharp edges" that make it
especially hard to write secure code in, and the best long-term strategy
is to change the language or switch to another language.

Old versions of PHP (particularly before 4.1.0) are _notoriously hard_
to use securely. For details, see:
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/php.html
(which is part of my free book on how to write secure programs, see:
http://www.dwheeler.com/secure-programs).

Here's a quote from that page:
"Granted, there are security issues in any language, but one particular
  issue  stands  out  in older versions of PHP that arguably makes older
  PHP  versions  less  secure than most languages: the way it loads data
  into  its namespace. By default, in PHP (versions 4.1.0 and lower) all
  environment  variables  and  values  sent  to  PHP  over  the  web are
  automatically  loaded  into the same namespace (global variables) that
  normal  variables  are  loaded  into  - so attackers can set arbitrary
  variables   to  arbitrary  values,  which  keep  their  values  unless
  explicitly  reset  by  a  PHP  program. In addition, PHP automatically
  creates  variables  with a default value when they're first requested,
  so  it's  common  for PHP programs to not initialize variables. If you
  forget  to set a variable, PHP can report it, but by default PHP won't
  - and note that this simply an error report, it won't stop an attacker
  who  finds  an unusual way to cause it. Thus, by default PHP allows an
  attacker  to  completely  control  the  values  of  all variables in a
  program  unless  the  program  takes  special  care  to  override  the
  attacker.  Once  the program takes over, it can reset these variables,
  but  failing to reset any variable (even one not obvious) might open a
  vulnerability in the PHP program."

 "...It's possible to disable this
  misfeature  in  PHP  by  turning  the  setting ``register_globals'' to
  ``off'', but by default PHP versions up through 4.1.0 default set this
  to  ``on'' and PHP before 4.1.0 is harder to use with register_globals
  off.  The  PHP developers warned in their PHP 4.1.0 announcenment that
 `as  of  the next semi-major version of PHP, new installations of PHP
  will  default  to  having  register_globals set to off.'' This has now
  happened;  as  of  PHP  version  4.2.0,  External  variables (from the
  environment,  the  HTTP  request,  cookies  or  the web server) are no
  longer registered in the global scope by default. The preferred method
  of  accessing these external variables is by using the new Superglobal
  arrays, introduced in PHP 4.1.0."

To their credit, the PHP developers realized that this was a big 
problem, and

made a _fundamental change to their language_ to make it easier to
create secure programs.  I haven't done the in-depth analysis to be able to
claim "PHP is secure" or "PHP is not secure", but at the very least, it's
worth commending the PHP developers for changing their language to
make it easier to write secure code.  I wish all language developers were
willing to do that when it's really important.  Transitions are always 
awkward,

but the PHP folks showed how to do it reasonably in a way that makes
it much more likely that developers won't make terrible mistakes.

--- David A. Wheeler