Slashdot Mirror
The Security of Popular Programming Languages
An anonymous reader writes "Deciding which programming language to use is often based on considerations such as what the development team is most familiar with, what will generate code the fastest, or simply what will get the job done. How secure the language might be is simply an afterthought, which is usually too late. A new WhiteHat Security report approaches application security not from the standpoint of what risks exist on sites and applications once they have been pushed into production, but rather by examining how the languages themselves perform in the field. In doing so, we hope to elevate security considerations and deepen those conversations earlier in the decision process, which will ultimately lead to more secure websites and applications."
I wonder how Ada 2012 would do in this test, although I don't know of any websites that use this language for a backend.
Do they mean Classic ASP? They list .NET separately so I don't think they mean ASP.NET, but they also don't include ASP in their list of "legacy" languages. I also seriously doubt 16% of companies are still using Classic ASP.
ASP isn't even a language, it's a framework. You can write a Classic ASP app in vbscript or javascript. You can write ASP.NET in any .NET supported language. Then there is ASP.NET MVC.
If they can't get their list of tested "languages" straight, I doubt the rest of the article.
I'm not even sure what the article meant by ASP vs .NET ? Surely they aren't talking classic ASP? I doubt anybody is 'starting new projects in classic ASP -- so what is ASP? and how is it not .NET ?
The rest of the article doesn't make a lot of sense to me either.
It may be cliche, but how secure a language is depends on who is using it. PHP is very accessible, and used by a lot of newbies, so "in the field" there turns out to be a lot of vulnerabilities found. However, by following some relatively simple guidelines, code can be made pretty secure. Most of the problems in PHP code are either due to SQL injection, which can easily be avoided by using parameterized queries, or from turning on options that are known to be insecure, like register_globals. C on the other hand would only be used by a small number of highly trained individuals, at least for web applications, so it's less likely to experience problems in the wild, but due to buffer overflows and other memory management problems, it's much easier to shoot yourself in the foot without realizing it.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
One bug that allows silent remote code execution on the WAN side and another bug that is a privilege escalation possibility on the LAN can not be treated as one bug each, right? This is not limited to just security vulnerabilities alone. Many software company top managers insist on looking at bug counts, sometimes sorted into 5 priority/severity levels or so.
It gets worse in the planning and progress monitoring. They use fancy tools like rallydev.com or something, but they allow each team to define its own story points. The Bangalore team uses 1 story point = 1 engineer week. The Boston team uses 1 story point = 1 engineer day. The Bangkok team uses engineer hour. And the top management gets the report, "This SAGA feature story was estimated to take 3264 story points, and it is 2376 points complete". Complete b.s. that is.
We pay ridiculously high salaries for the top management, and instead of expecting them to put in the time, energy and effort commensurate with that kind of pay, to make valuable judgement, hard decisions, step on people's toes, tell it like it is, and paint an accurate picture of the state of the company, we let them shirk their responsibilities.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
In the wake of Heartbleed, one might think that this would be talking about array bounds checking or buffer overflow mitigation. No. It is talking about web site frameworks.
examined the vulnerability assessment results of the more than 30,000 websites
First of all: this is not measuring the security of the programming language. This is measuring the security of the OS infrastructure and toolchains. Notice C/C++ is not on the list, since it is hardly ever used for creating web sites.
There was no significant difference between languages in examining the highest averages of vulnerabilities per slot.
What the heck is a slot?
Any summary where Perl scores the best must be deeply questioned. I doubt this is an apples-to-apples comparison. Surely these Perl sites are not doing nearly as much as the sites written in other languages.
It's the hip and cool language. If you owned vinyl records and were a vegan, like me, you would know that. But then again, I don't even *OWN* a TV and I was into that band way before they became all commercial. So I can't expect the rest of you to understand.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
If the language specification doesn't expressly say what happen when things "outside the design" happen, then different implementations may work differently.
For example:
If the language design spec says
"If an array index is out of bounds, exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program,"
that may seem very specific, but if how to "exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program," isn't specified by someone (usually the operating system), then it may not be specific enough. if different operating systems specify how to do this differently, then expected "under the hood" behavior will not necessarily be consistent across operating systems.
For example, does "exit the program" mean simply returning control to the caller, or does it mean explicitly returning any resources that were previously granted to the program by the operating system first? Or is that optional? If it's optional as far as the operating system is concerned, does the language provide a compile- or run-time switch to force such a cleanup? Does returning memory to the operating system guarantee that the OS will sanitize the memory, and if not, does the language guarantee it? If the language doesn't guarantee it, does the language provide a compile- or runtime switch so the program will sanitize memory prior to returning it to the operating system?
These differences in language implementations and even differences in how operating systems handle the starting and stopping of processes can lead to differences in what the code actually does. Usually these differences are unimportant but sometimes they are very important.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
php is not the worst because they measured completely the wrong thing. They measured how many bugs they found in the implementation of the language, not how many bugs a programmer using that language would introduce that the language would not catch for them.
I do not think C++ would have helped here, all it would have done was made things a bit more obscured. It should also be noted that you can build custom allocators in C++ too (I worked on a couple projects that used them) so that part of the problem would be there too.
C++ makes a lot of things easier, but under the hood it is still essentially C with an expanded library and fancy pre-processor (I know modern compliers do not actually preprocess C++ into C and then compile), thu all the same problems are still there and mostly are mitigated by using libraries that wrap things up in a safer way.
Hey, some of us find manual memory management sexually fulfilling, you insensitive clod!
SJW's don't eliminate discrimination. They just expropriate it for themselves.
(Can't believe I'm replying to an AC).
This sounds great and all that, but that's a very unreasonable statement. Consider C. I don't know a single person who would say that C is secure or that security wasn't built in from the get-go. The same can be said of C++. But those languages offer different benefits (speed and control both come to mind). It's a trade off, to be sure. But sometimes, you have to use a language that isn't secure "from the get-go" to build an application that needs security. We don't always have the luxury of doing the perfect (or near perfect) thing.
Ur/Web is an interesting language with a type system designed to reject vulnerable web programs as ill-typed. The compiler itself is written in a safe language — Standard ML, and there is a proof of language correctness included.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
The security level of a piece of code with good security is 95% coder competence and 5% language, i.e. language is irrelevant. One thing though is that language can add to the security problems if it has insecure tun-rime implementation errors.
One reason most security-critical software is written in C is that there, the coder gets full control. A good coder with skills in secure coding will do fine with C. A coder that does not understand software security will to badly in any language, but in C he/she might not even produce anything that works, which will be an advantage. Also in C, it will be far more obvious if somebody is clueless, which makes review easier.
But "language is important for code security" is even more wrong than "language is important for code reliability". Language is important for code performance though, but only in the sense that it can kill it. Good language choice can also make a good coder more productive (a bad coder has negative productivity, so it hardly matters...). This nonsense about the language being capable of fixing problems with the people using is comes from "management" types that are unable to handle people that are individuals. These utterly incompetent "managers" can be found in many large companies and they believe that in IT, individuals do not matter. Typically these "managers" are not engineers and have no clue what a good engineer can do but a bad one cannot. They also believe that engineering productivity can be measured in hours spent or that all coders are equal and just implement specifications, so outsourcing is a good idea.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I thought that PHP was born around the same time as Java (and definately way before .NET). So how is PHP a legacy language and Java isn't? Or, is the writer just throwing in words to mess with my programming language history?
I VOLUNTEER AS TRIBUTE ... but not for ColdFusion, ew.
I can't figure out how I would use this to make make a real-world decision. Just picking the "most secure" language overlooks so many other tradeoffs that I just can't see it as a valid approach, especially when the article ends with a call for more testing, not a call to select superior languages.
This is a non-finding.
Yes, it is indeed lucky for us that the competent OS developers know their stuff, and they don't listen to people like yourself who have no idea why C is better for the Linux kernel (or any kernel, really). I hate to break it to you, but you aren't smarter than the top Linux developers. You simply aren't. Stop confusing yourself into thinking you know more than they do. It is pathetic to watch.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
The problem with that is that many programming languages have "features" that programmers misuse resulting in security holes (especially in PHP).
If a language makes it difficult to do things safely, it's reasonable to blame the language.
At the end of the day, all programming languages are about abstracting things. If you are testing the intrinsic security of a programming language, you are in essence testing how successful the language's built-in data types, built-in functions, APIs, standard libraries, etc. are at mitigating risk factors, which is all about abstraction.
A language's intrinsic security is only as good as its abstractions.
> C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8.
That's because for most programming, UTF8 is not worthy of support. It's inconsistently used, it arbitrarily increases the of individual. It would be much safer used as only binary strings, not as actual characters which must be parsed and reformatted among different environments. The advent and popularity of UTF8 with its confusing and ill defined management of case and formally POSIX compliant operations such as file naming has effectively slowed system programming by many years.
People are still writing code vulnerable to SQL injection attacks?
Yes, they are. It doesn't help when lots of online tutorials give crappy information, like saying to use mysql_real_escape_string in PHP instead of a proper parameterized query. (Using the escape function is better than nothing, but it's not foolproof and is needlessly convoluted.)
This tutorial, which ranks first on Google when I search for 'php sql', uses the escape method and does not mention parameterized queries at all. (The correct method is described here.)
C++, properly written, is much more secure than C. It includes memory management, type-safe I/O, and well-behaved library containers.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
UTF8 is great for storing data in files, but ... working with strings in memory? Insanity will follow.
No sig today...
Except that I gave reasons why C++ is superior in security to C. It's easier to write secure code in C++ than in C. Both are difficult to write well, but well-written C++ code is going to be more secure than well-written C code.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes