Secure Coding mailing list archives
RE: Scripting Languages and Secure Coding + code
From: "Dave Paris" <dparis () w3works com>
Date: Fri, 05 Dec 2003 02:46:30 +0000
*NOTE* My intent with this post is not to disparage the developers of PHP, but to relate an experience and illustrate one of the fundamental problems with any language that attempts to extend it's core functionality too far (PHP just happens to be a handy, in-context, example) I am the maintainer of Crypt::Blowfish (among others) for Perl. A little while back, I had a PHP user send me a note wondering why ciphertext generated by Crypt::Blowfish couldn't be decrypted by PHP. They copied in the PHP developer responsible. After an exchange of mails, it came down to the fact that they never tested their Blowfish implementation against the test vectors, as supplied by Bruce Schneier, which would have uncovered a problem in their implementation of the Blowfish algorithm. Testing crypto implementations against test vectors is just another step in the implementation process to anyone who's worked with crypto implementations and the PHP folks responsible simply were unaware. I never bothered to investigate how potentially vulnerable it left the PHP users - I didn't have the spare time. If memory serves me, it was a fairly trivial error resulting in the swap of the ordering of a block. My point is that with a language such as PHP which tries to "be all things to all people" as opposed to Ruby, Perl, Python, etc which use modules created by [arguably] more subject-familiar individuals runs the risk of introducing other security holes which the programmer is completely unaware of and has little to no control over. Kind Regards to All, -dsp -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David A. Wheeler Sent: Thursday, December 04, 2003 11:22 AM To: SC-L Subject: Re: [SC-L] Scripting Languages and Secure Coding + code [...] 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. [...]
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)
- Re: Scripting Languages and Secure Coding + code securecodingorg (Dec 04)