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.'"
I have an hypotheses (Score:5, Insightful)
Its not black & white (Score:5, Insightful)
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.
Re:Duh (Score:4, Insightful)
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...
Re:The Python Paradox (Score:5, Insightful)
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.
Re:Its not black & white (Score:2, Insightful)
Re:Its not black & white (Score:3, Insightful)
Please show me the interpreted byte code langauge/runtime that has never had a buffer overflow exploit.
I promise you that I can count one one finger higher than you can show me systems without a buffer overflow exploit.
The fact that your saying what you're saying tells me you really have no understanding of how exploits happen at all, let alone any reason you should be talking about secure code.
Re:Everybody hatin' on PHP (Score:5, Insightful)
Re:The Python Paradox (Score:3, Insightful)
Re:The Python Paradox (Score:5, Insightful)
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.
Re:Its not black & white (Score:5, Insightful)
Yeah, except this isn't a comparison by language. It's a comparison by platform technology. For example, JSP shows as one of the highest vulnerability ratios, whereas Struts (Apache's Java MVC framework) has just about the lowest vulnerability ratio (on par with ASPX).
Clearly they are measuring *something* but it seems to have relatively little to do with languages themselves.
If anything, it seems like web apps written in frameworks that don't actively discourage mixing code and presentation are more likely to have vulnerabilities, whereas frameworks that encourage separation more actively (and perhaps are newer frameworks) are less likely to have vulnerabilities. The worst two measured, Perl and JSP, are older technologies that date from the era before frameworks that enforced more MVC separation were common and before web app best practices really existed.
Re:Its not black & white (Score:4, Insightful)
The test itself already has bias, precisely because it works on a family of programs that happen to have a very limited set of inputs, and where the avenues of attack are relatively limited in some very important ways. The core vulnerabilities of websites have been done to death, so at this point, barring utter stupidity, I'd have been surprised if the security problems were noticeably different depending on the language.
Java (Score:3, Insightful)
One of the things I liked about Java was that there aren't any buffer overflows to worry about. Well, apart from ones in the JVM, but they are few and far between.
I don't understand when people say that all languages are as insecure as each other. Sure, people can do stupid things like not check input, etc - but when it comes to finding some sort of buffer overflow in a function/library?
If I had to write a website that would be deployed onto a box which was not touched for 5 years, I imagine that a Java-based site would have a better chance of faring than a PHP one.
Re:Its not black & white (Score:5, Insightful)
"All languages are exploitable" != "all languages are equally exploitable".
You're the first person to bring the word "equally" into the conversation, and have missed the point.
Re:Its not black & white (Score:5, Insightful)
They made a statistical analysis of web languages. That's not generalizable to all programming languages as the Slashdot headline implies. All of these languages have several things in common:
In short, all of these programming languages eliminate entire classes of potential exploits that other programming languages allow. Therefore, although these programming languages happen to be similar, that does not mean that programming language choice has no bearing on security. It just means that choice of programming language within a very narrow range of languages that are not a representative sample of programming languages as a whole has no bearing on security.
A poor craftsman blames his tools (Score:2, Insightful)
Re:Its not black & white (Score:5, Insightful)
The difference is that flaws in the Java runtime (or any runtime) are A. infrequent, B. somebody else's fault, C. quickly fixed once discovered, and D. not specific to your individual installation. Thus, as long as you pay attention to the security notices, you're probably fine.
Put another way, there are thousands of people looking for flaws in the Java runtime. When you're talking about flaws in your code, the only people looking for bugs in it are you and the bad guys. This means that it is much more problematic to have 1,000 bugs in your code than to have 1,000 bugs in the Java runtime. With the latter, the odds are in your favor that the flaws will be first discovered against somebody else's website. WIth the former, the only place those flaws can be discovered is on your website.
Re:It's a good point but... (Score:3, Insightful)
Usually when you see claims that Java is more secure than C, it is based on people finding more security bugs in C than in Java, but I am not sure that is a good measurement because C and Java are used in different places, and that makes a huge difference. For example, a buffer overrun in a desktop app (excel, photoshop, whatever) is not a security breach, it's just annoying. C is used in a lot of system level code where errors do become vulnerabilities. So, I'm not sure that statistic is a very useful true measurement.
Looking at it from a practical point of view, almost every buffer overflow that you find in C is a string. Java has much better string libraries than C does, and they prevent overflows (they don't even give you access to the level where you could make overflows). So, if I were going to write webservices in C, I would create/find a decent string library that encapsulates all that, so I don't have to worry about string buffer overflows either. This would not be hard (you'd still have to worry about array overflows, but I can't think of a time that I've ever used an array in a webservice).
So really, I'm not sure there's a reason you couldn't write a webservice as securely in C as in Java. It's just a matter of setting it up right. BTW if you say C is insecure because of pointers, don't because they really are not a problem if you have the remotest idea of what you are doing.
Re:Duh (Score:1, Insightful)
But, hey, if you are a good programmer you know how to avoid them.
So then how do you explain the existence of these problems even in code written by supposed "good" or even great programmers?
Re:OVERSOLD/HYPED: 'Web programming language' (Score:1, Insightful)
Oh no! Someone is wrong on the internet. I must correct them.
What's missing, obviously, are 'real' programming languages such as C, Java, FORTRAN, Ada, C++, Eiffel, etc.
No, many of the test pages are "real" programming languages, for any definition of "real" used by reasonable people. JSP and DO are Java. ASPX is based on the .NET framework. PL is Perl.
A lot of these languages share a common (C) heritage, and I'd assert "inherit" a lot of the security weaknesses of C. That's particularly true of weak typing for scalars, including array bounds.
No, Java, Perl, and C# do not share a type system with C.
Re:False dichotomy much? (Score:3, Insightful)
In the case of an advanced JVM like HotSpot (the official Sun/Oracle JVM), you also get the performance back.
If the array bounds checking can be removed without compromising security, HotSpot's JIT compiler will do so when compiling the Java bytecode into native instructions.
Re:Duh (Score:5, Insightful)
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.
Re:Duh (Score:4, Insightful)
There are still tasks that are better suited for languages like C and C++. The interesting ones. The alternatives?
"You mean I get to build another boring business web application using the latest kludgy framework du jour so that it's obsolete two weeks later when the more popular kludgy framework comes out. Oh boy!" (OK, it's a little bit better than that. But not much. :) )
Games development, systems development, OS development, embedded programming and the like are places where it pays for development to be done by people who know what they're doing using tried and true programming tools that demand such expertise. When did Slashdot become so dull that nobody was interested in this stuff anymore?
Re:It's a good point but... (Score:5, Insightful)
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.
Never underestimate incompetence (Score:3, Insightful)
Never underestimate incompetence. Sure, Java protects you against some kinds of buffer overflows (but then a couple of versions had such vulnerabilities in their native parts of the JRE instead), but it doesn't protect against any other kind of incompetence.
There are probably a few SQL injection vulnerabilities and an XSS exploit being written somewhere right now. And someone out there is writing a servlet which reads and writes files off the hard drive, but isn't checking the paths, so really you can request the registry of that machine or anything. Someone else is putting a confidential document in there, betting on no more security than that nobody will think to look in that directory. Someone else is configuring a Lucene indexing and search which can bypass any access controls and find it. Someone else is coding a remote admin backdoor in the client's site, because it makes supporting it easier. Someone else thinks the users never reach pages except by clicking on the provided links, so he actually never checks parameters, and you can substitute your own id with the admin's ID on the page to change your password. (I've actually seen that one in a big money B2B site coded by expensive consultants from a big corporation.) Someone else out there is running half the company on the same user ID and password, because they can't be arsed to get a different password for the secretary than for the CEO, or because dealing with the IT department to get one involves more bureaucracy than that Asterix episode. (Invariably when some employee which used that account leaves the company, that account doesn't get its password changed or anything.) Yet someone else packs data the user shouldn't see or edit in hidden input fields or uses XPaths for input field ids, and blindly trusts whatever he gest back in those fields. (Then wonders why the user accepted the price for a Fiat 600 but could change the car model to a Lamborghini;)) Etc, etc, etc.
And, ironically, the myth that C is more dangerous than "sweating" dynamite while Java is physically impossible to break, only generates complacency in QA and hiring even less qualified burger-flippers for Java. I've seen I R Java Dev types which didn't even know what an SQL injection was before seeing it demonstrated to them. On the production machine.
And worse yet, you see a bunch of them arguing online, that SQL injection and XSS vulnerabilities are harmless and unavoidable, that the supposed danger is only hype, and that asking them to fix it is just stupid. And at least one such article was even linked to by Slashdot in the past.
Re:Duh (Score:3, Insightful)
Sure these categories of applications occasionally have bugs. They're difficult to do. What do you expect?
However, how often they happen are pretty exaggerated as well. The Linux kernel is mostly written in C, of course. How often do you see it lock up for as difficult of a piece of software that is to write? How about all the millions of embedded pieces of code for mission-critical application that perform flawlessly day after day to the point that nobody notices them?
Besides for every C++ desktop app that crashes, there's a Java equivalent that eats up memory until it's unresponsive. People only focus on the C and C++ varieties of problems because they're taught Java or something similar as a first language and assume that lower level languages must be unmanageably difficult.
Re:The Python Paradox (Score:3, Insightful)
That alone makes it the best language for large business projects. Your coworkers will be a mix of good and bad, and pretending the bad programmers is a more damaging mistake than anything you can do to the code.
Re:Duh (Score:3, Insightful)
We did all that years ago...it's only the uneducated C hackers who keep giving C++ a bad name.
Well, that and the facts that
anyway.
Re:Duh (Score:3, Insightful)
I didn't RTFA but I agree with the sentiment of the summary. It's NOT THE LANGUAGE, it's the programmer and their knowledge of the interfaces they are working with.
plenty of things can and should be written in C. It is perhaps a sharper blade than Java, but were professionals. There's 100 other mistakes you will make being uncareful when programming that have nothing to do with language choice that are far more important to worry about.
this checked exception hands tied stuff is worse than baby boomer nanny state bullshit
Not that huge a difference (Score:3, Insightful)
As you probably know already, virtually any CPU manufactured in the last years has some form or another of "no execute" flag. So someone could overflow your buffer all right, and... simply not be able to execute any code injected that way. And someone from the BSD gang could even add here that in their world they had a solution for that even before that.
And someone who is security-minded, since that was the thrust of the article anyway, will have used some C++ library or another that checks string bounds. Heck, it's trivial to write one yourself if you don't find one to your liking.
So being only 99% as vulnerable as before, well, still sucks.
In the end, the point isn't "Java sucks" or anything, but that basically the largest difference is in having your people be security minded. Between the team who programs in language X and is basically a bunch of paranoid pessimists who know that Murphy rules supreme and anything that can be broken will be broken, and the team who ploughs through language Y thinking the language alone lets them not bother with that kinda stuff, generally the former is the safest bet. Regardless of whether X = Java and Y = C++, or viceversa.
And knowing that about the prepared statements, or even that SQL injection can be a problem, well, that's already one step closer to the former.
Re:Its not black & white (Score:1, Insightful)
You're missing the point. Holes in the language aren't important, they're few and far between — and fixed quickly.
Security holes in code written in that language are important. I'm fairly sure I've never written a buffer overrun in my own code, simply because i use languages where it's impossible.
Re:It's a good point but... (Score:3, Insightful)
The problem is that *because* people are protected from certain very basic screw ups in Java companies automatically downgrade the quality of programmer and the level of oversight they use. The result, I believe, is that the end product is *even worse* than it would have been for the "more vulnerable" language.
So - if you are talking academically about languages - Java is more secure by a long way. C has all the vulnerabilities that Java has plus a lot more. If you are talking about actual outcomes in the real world - C is probably more secure. But this in no way means you can take the same sloppy programmers and methodologies that you used for your Java app, tell them to write in C and get a more secure product. Quite the opposite.