Choice of Programming Language Doesn't Matter For Security 192
An anonymous reader writes "The Security Ninja has written a blog post which discusses web programming languages and the fact that they are all insecure. It's based on a report from WhiteHat Security and aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages. '... secure code is the product of a secure development process and real business commitment to deliver secure applications which includes developer education. The absence of these processes and business commitments will lead to web applications being developed insecurely regardless of the language being used.'"
It's a good point but... (Score:2, Informative)
It's a great point that security awareness is paramount in any web programming...
But I dare you to write a more secure web service in , than in Java. Sure you have to be security aware, but it's still the case that some languages make acting on that awareness easier than others.
Re:Duh (Score:1, Informative)
True.
A system without any users is secure.
The Python Paradox (Score:4, Informative)
If you haven't heard of it, the python paradox is an interesting read: http://www.paulgraham.com/pypar.html [paulgraham.com]
Simply put, the kind of people who learn a language out of interest than out of wanting to get a job tend to be better programmers on average. (This was written awhile ago, when Python had little use outside the FOSS community. Now that Python is looking like it may someday replace Java, perhaps the Haskell Paradox is a better term).
Anyway, perhaps the same issue is at play here. Perhaps the people who use PHP tend to be less aware of security or more apathetic toward it, and thus there is a two way feedback between language and programmer (the last time I used Visual Basic the compiler was as full of holes as a piece of swiss cheese and Microsoft wanted me to pay $100 each to report counterexample bugs, but that was 6.0, back in middle school)
Re:Perl most secure (Score:3, Informative)
Re:Some truths are eternal (Score:1, Informative)
The exact quote is: "Besides, the determined Real Programmer can write Fortran programs in any language." It comes from a letter to the editor titled "Real Programmers Don't Use Pascal," attributed to an Ed Post.
Link. [pbm.com]
Re:Its not black & white (Score:4, Informative)
Well, the full paper is behind nag-ware, but here are the "top 3 findings"
Gosh. To me that says that they found significant differences between the languages and platforms.
However, I am not ready to make any claims based on this, other than, they sampled a bunch of websites and then recorded information about vulnerabilities, and did "group by" on language/framework.
Isn't it likely that there is some selection bias here?
Rather than making claims about the intrinsic nature of some language or framework [like all of them are equal, or one is better than the others], don't you need to correct for the lack of control.. like same coders in the same organization trying to implement the same _type_ of application?
If I gave the same group of developers equal traning time, equal implementation time, and equal specs... and then said "do this in ASP.NET", and then "do it in Perl". And i did this with 10 groups of developers, and i changed the order of which application came first (i.e. some groups did perl first, some did asp.net first).
__then__ I would feel comfortable saying something about the relationship between language/framework and security vulnerabilities. What we really want to know is, given developers _like yours_, who've had equal training, expertise, and time, when trying to produce equivalent functionality.. how is _their_ production of security defects, and is there a difference between toolchains?
Now, I didn't read the PDF because if the nag-wall infront of it. But that doesn't sound like what they did here.
The goal out here in the real world is this: make an application that is secure-enough, cheaply-enough. "Cheaply-enough" means what caliber of people you need to hire, and how long it takes them to produce value-adding output. Secure enough means that the cost of fixing your bugs is higher than the cost of (risk of penetration * financial impact of penetration).
Re:Its not black & white (Score:3, Informative)
The fact that stack crashing doesn't exist in interpreted code alone demonstrates that languages (or their runtime environments that are inherent to a language) are not all equal in exploit-ability levels.
You are totally wrong, since Javascript, which is interpreted, has numerous exploits involving stack crashing.
http://en.wikipedia.org/wiki/Heap_spraying [wikipedia.org]
with an example here:
http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit [stackoverflow.com]
ActionScript (from Flash) is also an interpreted language, and full of security bugs !
Re:Everybody hatin' on PHP (Score:5, Informative)
Changes in PHP 6
Issue: Register globals are the source of many application's security problems and cause a constant grief.
Discussion: We shortly discussed how we want to attend users on the disappearance of this functionality. We decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and some introduction on safe programming.
Conclusions:
We are going to remove the functionality.
We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting
http://www.php.net/~derick/meeting-notes.html#id12 [php.net]
Issue: Magic_quotes can be cumbersome for application developers as it is a setting that can be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts.
Discussion: In the same way as with the remove of the register_globals functionality, we decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and point the users at the input_filter extension as replacement.
Conclusions:
We remove the magic_quotes feature from PHP.
We throw an E_CORE_ERROR when starting PHP and when we detect the magic_quotes, magic_quotes_sybase or magic_quotes_gpc setting.
http://www.php.net/~derick/meeting-notes.html#id13 [php.net]
They are also planning on getting rid of the non-PDO db stuff at a future date.
Re:gets(), the C standard library standard bug. (Score:3, Informative)
gets() is officially deprecated in ISO C99 standard, though, and will be removed entirely in ISO C1X. Most compilers today (even non-C99 ones) will output a warning if they see it, and warnings-as-errors is standard development practice for C/C++ these days.
Also the "secure" functions in TR 24731 (strcpy_s, strcat_s etc [us-cert.gov]) will be part of the base standard library in C1X.