Slashdot Mirror
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.'"
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm afraid it's you who is insecure, not C...
Ezekiel 23:20
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.
You mean I am actually supposed to know what I'm doing?!
Careful. You might get him so mad that he'll have a buffer overflow and then core dump.
If you haven't heard of it, the python paradox is an interesting read: http://www.paulgraham.com/pypar.html
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)
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
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...
1. The languages being considered/charted are ASP, ASPX, CFM, DO, JSP, PHP and PL (I can guess at most of these acronyms).
What's missing, obviously, are 'real' programming languages such as C, Java, FORTRAN, Ada, C++, Eiffel, etc.
2. 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.
The conclusion I think can be drawn from this is that we need a substantial increase in Web Programming practices, including languages. Any other conclusion is overreach.
"My favourite programming language is a soldering iron".
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
I'm confused. When I was thinking of learning a new language a few years ago, I took a good look at them all (well, the top 5 to 10), and picked one based on how many jobs there were, pay levels, non-proprietary-ness, etc.
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.
Get your own free personal location tracker
I think this is more a testament to the fact that crappy programmers will write crappy code in any language, instead of showing that all languages are equally as crappy for writing secure code. If the same person wrote the same program in different languages then you might have a fair comparison, otherwise this report just shows a similar ratio of bad programmers across different languages which I don't find all that surprising.
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.
Mod me down, my New Earth Global Warmingist friends!
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
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?
Happy people make bad consumers.
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.
A polar bear is a cartesian bear after a coordinate transform.
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) will be part of the base standard library in C1X.
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.
Happy people make bad consumers.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yeah totally! Who's ever seen a null pointer dereference crash a Java program?
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
Long live the BSD license
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.
A polar bear is a cartesian bear after a coordinate transform.