Choice of Programming Language Doesn't Matter For Security
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.'"
I think that in average programs written in haskell (exempli gratia) tend to be more secure because it takes a better programmer to write them than a quick and dirty VB application.
In soviet russia the government regulates the companies.
'Cause even if the source is available, the would-be attacker won't be able to understand it!
Anyone who says all programming languages are equally exploitable is a fool. Sure, secure coding practices and standards are the way to approach the issue- not language selection, but it is, for instance, impossible to overrun a buffer in interpreted byte code and executed native code. 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. To say they are all the same is simplifying things too much. Yes, all languages have their exploitable bad practices, but some have more than others.
But I dare you to write a more secure web service in , than in Java.
I didn't know Whitespace supported web services.
Yeah cause a language that makes it trivially easy to overrun a buffer, dereference null pointers and smash the stack is clearly a highly secure language. Oh wait...
People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.
PHP really is that bad. Because they still haven't removed the cruft. If they were really serious about any kind of security, they would have gotten rid of magic quotes completely, as well as things like mysql_escape_string. Instead they left these gaping security holes in there, for the sake of compatibility. Meanwhile you have a bunch of cheap web hosts who turn things like magic quotes on by default, thinking it will solve all their customers' security problems, when really it just extends the problem by leading them down the wrong path. While they've added things (MySQLi/PDO for prepared statements, mysql_real_escape_string, and others) the amount of legacy stuff they left in there is amazing, and for a language with so many novices working with it, ends up being a real disaster.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I didn't know Whitespace supported web services.
Sure it does, I had a full shopping cart system at the end of my post by way of example.
Prove me wrong... :-)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Exactly. The culture of a language is as or more important than the language itself. Indeed, the culture shapes the language (but of course, to a degree, the language shapes the culture).
Java itself isn't a very good language, but it's the hordes of incompetent Java programmers who make it such a terrible choice for everything. This goes back to the Python paradox: companies want Python programmers to write Java for them.
I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest, and where the dumbest can't write code that does too much damage.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
Ye Olde Excuse: “you’re just not good enough”
You know, in modern languages, you can once abstract that concept out that you don’t want buffer overflows and dereference null pointers, and you’re done.
In C, you have to re-invent the wheel again and again and do the same micromanagement over and over. It’s like the man with three buttocks on Monty Python: We’ve done that! We’ve solved it. We have nice standardized solutions. (Java doing runtime checks by default. And Haskell doing them at compile time.) Use them!
With modern languages, you can use your mental resources to tackle the actual problem, instead of having to constantly think about decades old and long solved problems that should long be included by default.
And the biggest joke is, that most C programmers manually implement those systems themselves, and then act all proud, because they re-invented the wheel, except that it never received the literally decades of testing of the well-studied existing solutions.
It’s dumb. Like those people re-implementing standard library functions. It’s unprofessional and inefficient. And very error-prone for no reason at all.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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
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
They are also planning on getting rid of the non-PDO db stuff at a future date.
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
Bad choice of examples. That's what we were saying and thinking in 1998: IT to PHB: "Don't open any EXE files mailed to you, however Excel spreadsheets, Word docs etc, are fine".
A exploitable buffer overrun in any application where malicious inputs exist is a security hole.