Secure Coding mailing list archives
Re: Scripting Languages and Secure Coding + code
From: "David A. Wheeler" <dwheeler () ida org>
Date: Thu, 04 Dec 2003 19:26:34 +0000
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
Current thread:
- Re: Scripting Languages and Secure Coding M. Buchzik (Dec 03)
- Re: Scripting Languages and Secure Coding Timo Sirainen (Dec 03)
- Re: Scripting Languages and Secure Coding Martin Stricker (Dec 03)
- Re: Scripting Languages and Secure Coding + code Ghita Serban (Dec 04)
- Re: Scripting Languages and Secure Coding + code David A. Wheeler (Dec 04)
- RE: Scripting Languages and Secure Coding + code Dave Paris (Dec 04)
- Re: Scripting Languages and Secure Coding + code Andrew Rucker Jones (Dec 04)
- Re: Scripting Languages and Secure Coding + code Paul R. C. Ming (Dec 04)
- Re: Scripting Languages and Secure Coding + code David M. Wilson (Dec 05)
- RE: Scripting Languages and Secure Coding + code Dave Paris (Dec 07)
- Re: Scripting Languages and Secure Coding + code ck (Dec 08)
- Re: Scripting Languages and Secure Coding + code ck (Dec 08)
- Re: Scripting Languages and Secure Coding + code David M. Wilson (Dec 09)
- Re: Scripting Languages and Secure Coding + code Carsten Kuckuk (Dec 09)
- Re: Scripting Languages and Secure Coding + code David A. Wheeler (Dec 04)