Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Security of Popular Programming Languages

Soulskill posted about 4 months ago | from the new-ways-to-argue-about-your-favorite-language dept.

Programming 189

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."

cancel ×

189 comments

Sorry! There are no comments related to the filter you selected.

Wonder how Ada 2012 would fare... (4, Interesting)

mlts (1038732) | about 4 months ago | (#46759845)

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.

Re:Wonder how Ada 2012 would fare... (0)

Anonymous Coward | about 4 months ago | (#46759929)

It would fare pretty well imo. But it's not really general purpose in this context is it ?

Re:Wonder how Ada 2012 would fare... (1)

TechyImmigrant (175943) | about 4 months ago | (#46759977)

Why not?

Re:Wonder how Ada 2012 would fare... (0)

Anonymous Coward | about 4 months ago | (#46760139)

Well, for one thing, Ada compilers do not run on the same range of platforms C compilers do (I'm sorry to say).

Re:Wonder how Ada 2012 would fare... (0)

Anonymous Coward | about 4 months ago | (#46760255)

Wrong, gnat uses gcc as a backend and supports pretty much everything gcc does -- and this month Ada for android was released (although you have to pay for that one).

Re:Wonder how Ada 2012 would fare... (0)

Anonymous Coward | about 4 months ago | (#46760491)

No, you are wrong. Look at the number of supported code generation targets for GNAT compared to C (and make sure you include all the embedded, bare metal and cross compiled targets Ada code will not currently run on).

Re:Wonder how Ada 2012 would fare... (1)

luis_a_espinal (1810296) | about 4 months ago | (#46760455)

Well, for one thing, Ada compilers do not run on the same range of platforms C compilers do (I'm sorry to say).

Uh, you are conflating "general purpose" with "platform availability". C runs in far more platforms than, say, Java, but, from professional experience as a C/C++ and Java programmer, I would not call C more of a general purpose language in the same way I would do so with Java.

Re:Wonder how Ada 2012 would fare... (1)

luis_a_espinal (1810296) | about 4 months ago | (#46760703)

Well, for one thing, Ada compilers do not run on the same range of platforms C compilers do (I'm sorry to say).

Uh, you are conflating "general purpose" with "platform availability". C runs in far more platforms than, say, Java, but, from professional experience as a C/C++ and Java programmer, I would not call C more of a general purpose language in the same way I would do so with Java.

Replying to myself since we have no way to edit our previous posts - I would add that languages of the BASIC and XBase families (in particular VB and FoxPro) are/were more general purpose than either C/C++ or Java despite running in more restricted sets of hardware platforms.

Re:Wonder how Ada 2012 would fare... (1)

HiThere (15173) | about 4 months ago | (#46761033)

Perhaps you need to define what you mean by "more general purpose". I tend to consider C the most general purpose of languages, because it *isn't* specialized to some task. It's true that , e.g., FoxPro was better at interfacing to the FoxPro database, but that's NOT being general purpose, that's being special purpose.

OTOH (to get back on thread) I don't consider C a very secure language BECAUSE it is lacking in specializations. This means you need to keep creating, e.g., hash tables from scratch, and every time you do it you are likely to introduce an error.

Ada is in an in-between state. It's very secure against some types of errors. The facility for defining specific types is a particular instance. If one defines a meters type, then one cannot store an inches type into it...unless one uses a numeric literal, because one needs to allow instances to be created from numeric litrals. OTOH, this very security introduces verbosity, and verbosity is a common entry point for errors. (I used the meters/inches example because of the nortorious example of the space probe where that was misused. Ada did NOT save the day. And the reason that it didn't was because doing things properly would have been too verbose.)

In principle, every "Turing complete" language is as general purpose as every other. Practical considerations are the distinction between them. If you're doing database programming, then you are less likely to make mistakes if you use a language that contains extensions specialized to make database use easier. (I barely count embedded SQL, because while SQL is reasonably great for manipulaitng databases, it's lousy at interfacing to programming languages. Everything either needs to be converted into a string, or a blob, and blobs are clumsy to handle.) But note that these "databse extensions" are specializations away from "general purpose".

Re:Wonder how Ada 2012 would fare... (0)

Anonymous Coward | about 4 months ago | (#46761363)

Now you are weasel-wording. "General purpose" has a specific meaning when it comes to computer languages, and it is completely distinct from "Turing complete."

Re:Wonder how Ada 2012 would fare... (1)

Anonymous Coward | about 4 months ago | (#46760903)

Isn't the context of the article about running software on servers, not bare metal or embedded applications?

Re:Wonder how Ada 2012 would fare... (0)

Anonymous Coward | about 4 months ago | (#46761045)

The same libraries which run on those servers may very well be the same libraries which need to run in those embedded environments.

And don't forget Heartbleed was about a library used in a large range of environments, not some restricted usage application.

You need to able to code that library in a language which will run in that range of environments. I wish that language was Ada or something similar but it's unfortunately not viable to write OpenSSL in Ada because of the wide range of environments that library needs to run in.

Re:Wonder how Ada 2012 would fare... (0)

Anonymous Coward | about 4 months ago | (#46760021)

No, but using Ada or another Wirth style language would be a good idea to write some of the critical security libraries in.

Of course, we would have to make sure they are written in such a way to make them callable from C or other languages without too much hassle.

Re:Wonder how Ada 2012 would fare... (1)

Daniel Oom (2826737) | about 4 months ago | (#46760085)

Poorly, but not as badly as C, but as it turned out, COBOL was the most secure programming language after all.

Re:Wonder how Ada 2012 would fare... (1, Funny)

Anonymous Coward | about 4 months ago | (#46760181)

That's because even legitimate programmers can't get COBOL to do anything.

Re:Wonder how Ada 2012 would fare... (1)

gbjbaanb (229885) | about 4 months ago | (#46760591)

rubbish. I can get it to do merging of sorted payroll data and, erm.. and.. and... yeah ok.

Re:Wonder how Ada 2012 would fare... (1)

luis_a_espinal (1810296) | about 4 months ago | (#46760521)

No, but using Ada or another Wirth style language would be a good idea to write some of the critical security libraries in.

Of course, we would have to make sure they are written in such a way to make them callable from C or other languages without too much hassle.

Most modern Wirth-style languages posses syntax-level compiler directives to specify the calling convention. Heck, most modern languages either have such a capability, or an intermediary wrapper or stub generator to do that type of bridging. </itisasolvedproblem>

Re:Wonder how Ada 2012 would fare... (2)

HiThere (15173) | about 4 months ago | (#46761109)

It's hardly a solved problem. There are approaches that can be made to work, but that's not the same thing. The current approaches are all clumsy, and often that's a charitable description. It's usually doable. Saying anything beyond that is fulsom praise.

OTOH, because different languages have different basic derived structures, it's often not clear exactly what the best approach would be, even when one is considering things carefully. For one purpose the best I've been able to come up with is marshalling everything into a byte array, and then separating it back out. Doable, but hardly what I'd call "a solved problem". Probably an insoluble problem because the different languages map the same concept differently internally. So you need to deal with it on a special case by special case basis.

Re:Wonder how Ada 2012 would fare... (1)

Hognoxious (631665) | about 4 months ago | (#46761321)

For one purpose the best I've been able to come up with is marshalling everything into a byte array, and then separating it back out.

Have you thought about XML?

(If you're not sure whether I'm joking that makes two of us)

Re:Wonder how Ada 2012 would fare... (1)

jythie (914043) | about 4 months ago | (#46760033)

I would wager that even if some sites do have it as a back end, they are too rare for this type of experiment or the back ends are not sufficiently exposed for it to matter. That being said, yeah, if I had to start from scratch in all regards and write a secure service as the primary priority, Ada would probably make make it to my short list of languages.

On the Other Hand (1)

Anonymous Coward | about 4 months ago | (#46759851)

Who exactly is going to volunteer to implement a major system in a combination of Perl and ColdFusion?

Captcha: jokers

Re:On the Other Hand (2)

preaction (1526109) | about 4 months ago | (#46760345)

I VOLUNTEER AS TRIBUTE ... but not for ColdFusion, ew.

python?! (1)

Anonymous Coward | about 4 months ago | (#46759875)

where the hell is it on the list?!

-db

Re:python?! (5, Funny)

NotDrWho (3543773) | about 4 months ago | (#46760013)

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.

Re:python?! (0)

Anonymous Coward | about 4 months ago | (#46761335)

This is totally not fair. I'm fine if some asshat wants to tell me python sucks, but I have been using it for fifteen years now, and there's just no way it could possibly still be hip and cool.

Continuously hip forever is an impossibility! (Isn't it?)

Re:python?! (1)

TeknoHog (164938) | about 4 months ago | (#46761359)

Oh yeah? Well I was ranting about global warming before it was cool.

Subtle attack against C/C++ (0)

Anonymous Coward | about 4 months ago | (#46759877)

Here we go again with another subtle attack of C/C++ in wake of the recent HeartBleed.

Let's just keep pushing the idea now despite every other language for the most part being implemented in C/C++.....

C++11 is awesome and has brought it back to modern day relevancy. I'm pushing C++11 all over my projects and teams.

Re:Subtle attack against C/C++ (-1, Troll)

Joce640k (829181) | about 4 months ago | (#46759941)

The problem lies squarely with C.

If they'd used C++ instead of C, heartbleed would never have happened - std::containers don't need to store their size as a separate variable.

Luckily for us, the people responsible for maintaining the Linux Kernel understand the difference between C and C++ and their software isn't full of manual memory management and arguments over which version of malloc()/free() to use. Oh, wait...

Re:Subtle attack against C/C++ (3, Insightful)

jythie (914043) | about 4 months ago | (#46760095)

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.

Re:Subtle attack against C/C++ (2)

InvalidError (771317) | about 4 months ago | (#46760657)

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.

Re:Subtle attack against C/C++ (5, Funny)

NotDrWho (3543773) | about 4 months ago | (#46760101)

Hey, some of us find manual memory management sexually fulfilling, you insensitive clod!

Re:Subtle attack against C/C++ (0)

Anonymous Coward | about 4 months ago | (#46760849)

Mmmm, manual memory management. Is it hot in here or is it just me?
Pointer arithmetic, offsets, alignment...
Grrrrr

Re:Subtle attack against C/C++ (1)

oldhack (1037484) | about 4 months ago | (#46761029)

Hey, enough jokes from you today. You're way over the quota. What, are you getting a big fat refund?

Re:Subtle attack against C/C++ (2)

Zero__Kelvin (151819) | about 4 months ago | (#46760445)

"Luckily for us, the people responsible for maintaining the Linux Kernel understand the difference between C and C++ "

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.

Re:Subtle attack against C/C++ (1)

Qzukk (229616) | about 4 months ago | (#46761237)

std::containers don't need to store their size as a separate variable

C strings don't either. It's the protocol that said "hey, rather than null terminating strings, let's put a length byte like Turbo Pascal never went out of style!"

The fun thing is that that design decision has lead to an entire CLASS of SSL bugs (in all stacks, not just openSSL) eg invalid certs validating because of a null byte in the Common Name. And heartbleed was just one more in that heap.

Re:Subtle attack against C/C++ (1, Insightful)

HiThere (15173) | about 4 months ago | (#46761259)

C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8. And the absurd part of it is that they could easily do a good job. Utf8 is just a byte array with various routines to interpret the code. Glibc does a reasonable job for a C library...not ideal, but reasonable.

All the array needs is a way to address a chunk by character # rather than by byte #, a way to copy of a character or a slice of chars, and a way to determine the general character classification of any character. Also a few methods: first(), last(), hasnext(), hasprior(), next() and prior(). And these all "sort of" exist, except getting the general character classification. (Do note that these functions need to operate on utf-8 characters rather than on bytes.) But several different ways of doing this are already known. Vala, e.g., handles it without difficulty, and is able to emit C code (using Glibc libraries).

So it's not a programming difficulty that's holding things up. It's the standards bodies...or, perhaps, some members of them.

But I've looked at C++11, and it is not a satisfactory answer. Vala has a good answer. D (Digital Mars D) has a different good answer. Even Python3 has a pretty good answer. (I don't like that in Python you can't determine memory allocation within the string.) Also Racket, etc. But C++ doesn't.

Re:Subtle attack against C/C++ (1)

jythie (914043) | about 4 months ago | (#46760047)

Neither is on the list, so I am not sure this is much of an attack.

Re:Subtle attack against C/C++ (0)

Anonymous Coward | about 4 months ago | (#46760193)

hence subtle....

Re:Subtle attack against C/C++ (0)

Anonymous Coward | about 4 months ago | (#46760831)

That would make sense since this article would make your heartbleed...it is very c sharp...

Contradict often? (0)

Anonymous Coward | about 4 months ago | (#46759891)

I've never read so many contradictions in one article before!

Methodology for choosing languages? (1)

Vultaire (603911) | about 4 months ago | (#46759907)

From the article: "To lay the foundation for the research, the team first examined the volume of languages in the field, and found, unsurprisingly, that .Net, Java and ASP are the most widely used programming languages at 28.1%, 25% and 16% respectively. Legacy programming languages that have been around for decades, PHP (11%), ColdFusion (6%), and Perl (3%) rounded out the remaining field." How did they determine the languages? This certainly differs from TIOBE's methodology (based on Google searches). The "unsurprisingly" seems suspect as well; I feel some of the selections *are* somewhat surprising.

Re:Methodology for choosing languages? (0)

Anonymous Coward | about 4 months ago | (#46759949)

Yeah, I thought PHP was still more prevalent than that.

Re:Methodology for choosing languages? (1)

Ziggitz (2637281) | about 4 months ago | (#46761075)

Sadly, it is.

Re:Methodology for choosing languages? (1)

pr0fessor (1940368) | about 4 months ago | (#46760185)

WhiteHat researchers examined the vulnerability assessment results of the more than 30,000 websites to measure how the underlying programming languages and frameworks perform in the field

It's a small sample size if you said that they were all enterprise web applications I would expect that .Net and Java usage would be even higher.

Re:Methodology for choosing languages? (3, Insightful)

sporkbender (986804) | about 4 months ago | (#46760271)

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?

Re:Methodology for choosing languages? (1)

Shados (741919) | about 4 months ago | (#46761049)

They came out around the same time, but their popularity as a web development language was separated by quite a few years. PHP was everywhere a few years before JSP and Servlets started powering bank websites all over the place.

ASP? (5, Insightful)

BaronAaron (658646) | about 4 months ago | (#46759931)

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.

Re:ASP? (1)

Richard_at_work (517087) | about 4 months ago | (#46759997)

There are also non-ASP.Net MVC frameworks based on .NET, like NancyFX, so the .NET category seems to very very wide. At a guess I'm going to assume the same for Java, as its really the same situation.

Re:ASP? (2)

FearTheDonut (2665569) | about 4 months ago | (#46760123)

Yes, but it's far easier to say, ".NET is .NET", or, more accurately, "Microsoft is Microsoft". i.e. Proprietary.. i.e. bad. While I don't have numbers, I'd wager that Classic ASP (which runs on the .NET framework) is vastly more unsecure than ASP.NET MVC.

Don't mistake my comment for blind support for Microsoft. But, when a study fails simply acknowledge this very basic fact about the Microsoft ecosystem, it's numbers really don't mean much.

Re:ASP? (1)

Richard_at_work (517087) | about 4 months ago | (#46760263)

Classic ASP doesn't run on .NET, it was pre-.NET.

Re:ASP? (0)

Anonymous Coward | about 4 months ago | (#46760489)

I'd wager that Classic ASP (which runs on the .NET framework)

Active Server Pages (Classic ASP) pre-dates .NET and has nothing to do with .NET. It is a legacy technology. ASP.NET was a replacement for ASP built on top of .NET.

ASP and ASP.NET are two completely different things.

Re:ASP? (1)

amicusNYCL (1538833) | about 4 months ago | (#46761407)

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.

That's right, according to them ASP and Java are new, and PHP is legacy.

Confusing (3, Insightful)

vux984 (928602) | about 4 months ago | (#46759933)

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.

Depends on who uses them (5, Interesting)

CastrTroy (595695) | about 4 months ago | (#46759951)

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.

Re:Depends on who uses them (4, Funny)

jellomizer (103300) | about 4 months ago | (#46760057)

That can't be, My choice language has been told to be the most secure ever.
So
Input $Login
Input $Password
Let $LoginID= SQLQuery("SELECT LoginID from Logins where Login = '" $Login "' and Password = '" $Password "'

I am can rest comfortably knowing that I am perfectly secure.

Re:Depends on who uses them (4, Insightful)

parkinglot777 (2563877) | about 4 months ago | (#46760245)

If you read TFA, you will find out quickly that the headline (both from this site and on TFA) is seriously misleading! What TFA is talking about is doing statistic on 30k websites, and determine what language/frame work they used to implement. Then check on each of them for vulnerability attack, such as SQL injection, XSS, etc. So, the language itself has NOTHING to do with the security, but it is the implementation of the site itself! The article itself is not well written either... Too many quotes from many people in copy-and-paste style. Then the author tries to thrown in numbers (i.e. percentage of this and that) to make it look like it is that useful... NOT!

TLDR? Below is what TFA is actually about...

WhiteHat researchers examined the vulnerability assessment results of the more than 30,000 websites to measure how the underlying programming languages and frameworks perform in the field. With that information, the report yields key findings around which languages are most prone to which classes of attack, for how often and how long as well as a determination as to whether or not popular modern languages and frameworks yield similar results in production websites

Re:Depends on who uses them (1)

CastrTroy (595695) | about 4 months ago | (#46760337)

Exactly. Perl had the fewest vulnerabilities. But only the most experienced coders would even attempt to do a site in Perl, so you kind of end up with exactly what you expect. The popular languages all ended up with the same number of vulnerabilities. It's actually quite surprising the PHP had slightly fewer vulnerabilities than .Net and Java.

What would be really secure would be a language that actively tried to stop you from doing stupid things like requiring that database queries be parameterized. Don't provide any APIs for running database queries without parameters. Sure you could still construct queries that didn't actually use the parameters, but it would at least get you off to a good start by forcing you to pass them into the function. You could even parse the SQL and throw an error if a value was used where a parameter should be. You could also force checking for a token when submitting forms to ensure CSRF is not being done.

Re:Depends on who uses them (0)

Anonymous Coward | about 4 months ago | (#46760999)

What would be really secure would be a language that actively tried to stop you from doing stupid things like requiring that database queries be parameterized.

have you seen ruby on rails or django or ... on and on and on? pretty much every web framework that's come out in the last 10 years?

Re:Depends on who uses them (0)

Anonymous Coward | about 4 months ago | (#46760719)

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.

Too bad when you go around looking for example PHP code for SQL, you don't find parameterized code. Then PHP is weakly typed, so something as inoculus as FindIndex(MyArray, "MyString") can return "false", but "false" is equal to "0", which is a valid index. Oh great, how do I know if it found something at index 0 or it returned false because it couldn't find it. Great f'n language. They may have fixed this one annoyance, but there are many more that are just as bad or even worse.

PHP has a lot of ambiguity and goes out of its way to make sure code runs, even if it makes no sense. Personally, I like it when my code creates an error and fails, instead of giving a false impression of "working".

PHP not the worst!!!! (0)

Anonymous Coward | about 4 months ago | (#46759953)

WOOT

Re:PHP not the worst!!!! (2)

beelsebob (529313) | about 4 months ago | (#46760089)

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.

PHP IS the worst (1)

Nicholas Allevato (3521495) | about 4 months ago | (#46761131)

The fact that the holes exist is what they're talking about.

If you want real security (0)

Anonymous Coward | about 4 months ago | (#46759955)

You have to build security into a language from the get-go. It can't be an afterthought.

If you're comparing mitigation rates, it just means you've failed already.

Re:If you want real security (2)

FearTheDonut (2665569) | about 4 months ago | (#46760165)

(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.

Re:If you want real security (1)

Anonymous Coward | about 4 months ago | (#46760677)

(Can't believe I'm replying to an AC).

Why do so many people feel the need to point out that they're stooping below their normally high standards to "reply to an AC"? Either the guy said something that made sense or he didn't. Who cares if he was anonymous? And why lead with that in your reply when it has nothing to do with the discussion at hand?

Mean number of vulnerabilities is a good metric? (3, Insightful)

140Mandak262Jamuna (970587) | about 4 months ago | (#46759969)

When you reduce a complex issue to just one number, like "mean number of vulnerabilities", it is often an over simplification. It is tempting to think it is better than nothing. But are we really better off making decisions based on an overly simplified view of things?

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.

The language being the problem? Seriously? (1)

Opportunist (166417) | about 4 months ago | (#46759995)

Yes, of course the security of your language (as well as the rest of your environment) matters. But what's way more important is what kind of devs you have. No matter how secure anything is, if the person supposed to use it does not know about its security pitfalls, do you think that's increasing the security?

Security is by definition the minimum of the security your technology offers and the security your personnel offers. The minimum. Not the average. The same applies to OSs, too. You can have the most secure OS in the world, if you lack the admin to secure it, you're no better off than with an OS that has shabby security itself.

Your security is way more dependent on the personnel you have, and the ability and expertise they have with the different technologies. Simple scenario: Take an admin that knows OS-A like the back of his hand and can somehow kinda-sorta get OS-B to run. OS-A has a few security holes (that the admin all knows about, including their workarounds) while OS-B is absolutely tight but our admin doesn't know it too well.

Which one do you think will, administered by said admin, be more secure?

It's the same with programming languages. C does have its security issues, but a good C programmer knows why he should not put input on the stack and why he should include sanity checks on every input, especially if is of variable length. Some other language might not have that possibly dangerous pit, but there are very, very few languages (outside those fields where security matters and money doesn't) that have none.

What would you prefer your devs to develop in? A language they know, including all its slings and errors, or a potentially more secure one the pits of which your devs don't know?

ColdFusion is a PROGRAMMING LANGUAGE? (0)

Anonymous Coward | about 4 months ago | (#46759999)

These aren't really "programming languages", they're a set of "web scripting languages".

Some of them may be "programming languages", too.

But damn, talk about delusions of grandeur.

Not a useful paper (5, Insightful)

MobyDisk (75490) | about 4 months ago | (#46760007)

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 not just the language, but the implementation (4, Insightful)

davidwr (791652) | about 4 months ago | (#46760015)

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.

Re:It's not just the language, but the implementat (1)

davidwr (791652) | about 4 months ago | (#46760321)

DOH! I *knew* I should've read the freakin' article before writing that.

Obviously, the article is talking about scripting languages, languages that (typically) run inside of a hopefully-OS-independent-behavior runtime rather than a traditional compiled language that doesn't contain a lot of "runtime" between the compiled code and the operating system.

CSS ? (0)

Anonymous Coward | about 4 months ago | (#46760019)

Programming languages. Vulnerabilities of programming languages (read: sub-optimal implementation of the language).

Then you read "CSS", as in Cross Side Scripting ? And SQL injections ? C'mon...

This is completely unrelated to the programming language. TFA is completely absurd, despite stating that these are "(...)vulnerability assessment results of the more than 30,000 websites to measure how the underlying programming languages and frameworks perform in the field"

We all know that most web development it's recently done with .net. Java is also widely used, so as ASP. So, the so-called "vulnerabilities" are obviously linked to the most-used platforms.

Nothing new here for you to read, move along.

FLAME WAR! (1)

HeckRuler (1369601) | about 4 months ago | (#46760043)

FLAME ON! PURGE THE INFIDELS IN THE HOLY FIRE!
But before we really get into it, this isn't really a measurement of the language somuchas how people use the language. For example: while VB6 was an abomination, VB.NET really isn't all that bad. But since the people who use VB.NET are the amateur noobs who make stupid mistakes. Hey, we all started somewhere. But it means I really wouldn't trust a project that's written in VB.NET for certain tasks.

These are sociological factors. Politics. Culture. And they matter, but they're not technical aspects. The size of the community. The maturing of the developers. How open the overlord megacorp is to people making tools that interface with their toys. How many developers got the hype-bug and wrote libraries for said language. How good those developers were at their job. It all matters, but it's not an aspect of the language itself.

Any Turing complete language CAN do the job. You've got to avoid Turing tarpits, but mostly the right tool for the job is a matter of fashion.

Why the flames? Why is this something that causes so much strife?
Because we all want to bet on the right horse, and who wins is largely a popularity contest. It really DOES matter what the community does. You can't just go off into the woods and code away in TurboPascel and hope to have a lucrative career. It's an inverse tragedy of the commons. Using the tools of your neighbor SHARPENS said tools. So everyone wants you to use their tools. Because their tools are the best.

And so the flame wars rage on.

Re:FLAME WAR! (0)

Anonymous Coward | about 4 months ago | (#46760083)

Pascal. Delphi was the bomb in it's day (late 90s, early 00s). It got out marketed though. Borland exec's were pretty stupid too. Inprise my ass.

Re:FLAME WAR! (1)

Shados (741919) | about 4 months ago | (#46760107)

The example you give is a decent one, because there's an easy comparison point: C#. VB.net and C#, aside for unsafe block, inline event handlers, XML literals, VB6 compability assemblies and a few other minor things, are exactly the same. They compile to the exact same bytecode, byte for byte, if you write the same thing in both.

Yet VB.net devs are paid less, VB.net code is almost universally worse, VB.net companies are generally garbage, even though the 2 language are almost exactly the same, because of all the factors you already pointed out.

Completely missing the point (1)

beelsebob (529313) | about 4 months ago | (#46760065)

They shouldn't be looking at the number of bugs in the implementation of the language. They should be looking at the bugginess (or not) of the code written in it. That's the important thing.

Re:Completely missing the point (2)

BenSchuarmer (922752) | about 4 months ago | (#46760449)

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.

Re:Completely missing the point (1)

beelsebob (529313) | about 4 months ago | (#46760467)

Yes... That's my point. This is exactly what they should be testing for - does the language allow you to do dumb things, or does it moan at the first sign of something that could be insecure? This is what they should have tested. Not whether the implementations were any good.

I always knew (0)

Anonymous Coward | about 4 months ago | (#46760113)

that PHP was more secure than Java

JAVA For Security and Speed! (0)

Anonymous Coward | about 4 months ago | (#46760129)

JAVA is Secure, Java is also fast. But Java Interpreters/compilers are not written in Java.

So we need to have a java interpreter, running on a java interpreter, written in java, recursively.

Just think how fast and secure that will be!

Who needs a 1 second boot when u have a 3 month boot time, good luck exploiting that!

Security by wearing down your opponent!

More Important Is Ease of Writing Secure Programs (2)

Unknown Lamer (78415) | about 4 months ago | (#46760167)

Ur/Web [impredicative.com] 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 [impredicative.com] included.

The whole approach is wrong (4, Insightful)

gweihir (88907) | about 4 months ago | (#46760183)

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.

Re:The whole approach is wrong (2)

EvanED (569694) | about 4 months ago | (#46760405)

A good coder with skills in secure coding will do fine with C.

I conclude from this and the list of security vulnerabilities in real life that there is no such thing as "a good coder with skills in secure coding."

Or at least no such thing as a project that only employs or accepts contributions from such programmers.

Re:The whole approach is wrong (1)

Arker (91948) | about 4 months ago | (#46761253)

"Or at least no such thing as a project that only employs or accepts contributions from such programmers."

You could probably find a few drawing decent salaries in less public areas, but certainly it's a skill that the tech world in general has no appreciation for at all. And even though I hate it I can understand why - if you have two companies developing a similar product, one does it quick and cheap, the other takes the time to do it right - the first one will 'own the market' before the second can get there. And with that position it has the cash flow to keep paying programmers, while the second one closes their doors.

The same dynamic still plagues non-commercial projects as well, a quick but shoddy project can gain mindshare and take off before one that does things right has a product to show at all.

There are a few places where people are willing to pay the price for secure code, and the way things are going I suspect that is increasing, but it's still a tiny minority of available positions.

There's a reason Republicans... (-1)

Anonymous Coward | about 4 months ago | (#46760199)

still push C. It's because they want to be able to break into our systems. That is why they still push it. That is why they still force universities to teach it. They hate us for wanting secure systems.

Strange choice of languages (0)

Anonymous Coward | about 4 months ago | (#46760203)

"The most popular programming languages"? Really? Where are Javascript, Ruby, Python, the Cs? On the other hand, is anyone still using ColdFusion? (Which is, or used to be, not even a language but a framework.)

APL (1)

stox (131684) | about 4 months ago | (#46760205)

Not a single security exploit reported in over 50 years.

Re:APL (1)

bazmail (764941) | about 4 months ago | (#46760343)

Is anyone looking?

Re:APL (1)

Misagon (1135) | about 4 months ago | (#46760915)

Large systems are still being done in APL.

The Swedish medical journal system TakeCare is one example. It handles practically all journals in the greater Stockholm area. It has sure had its slew of security problems, although I don't think that those could be attributed so much to the language as to sloppy sysadmins.

But hey... a few years ago I thought that nobody would use Erlang for anything significant, until it became a popular language for web services.

ISO study on programming language vulnerability (1)

david.emery (127135) | about 4 months ago | (#46760231)

http://www.crosstalkonline.org... [crosstalkonline.org]

And here's my $.02: C syntax has been actively harmful in this regard. It's too easy to make a typo that compiles, or to introduce a statement/expression that has a different result than you expect (e.g. the Apple "extra break statement" bug.)

How does a language remediate anything? (1)

hawguy (1600213) | about 4 months ago | (#46760323)

I don't understand this:

Perl remediates 85% of all Cross-Site Scripting vulnerabilities, the highest rate among all languages but only 18% of SQL Injection.

There is no Perl language support to remediate cross site scripting. That's all done by the developer and/or framework he's using, so I don't see how it's useful to say that Perl remediates 85% of XSS vulnerabilities when the language itself has no idea what XSS is or how to remediate it.

I'm also having trouble reconciling this statement:

Perl has an observed rate of 67% Cross-Site Scripting vulnerabilities, over 17% more than any other language.

So Perl re mediates 85% of XSS vulnerabilities -- the highest rate of any language, yet it has a 17% higher rate of XSS vulnerabilities?

This study would be slightly more useful if they gave details on web frameworks instead of just languages.

I'm surprised Ruby and Python didn't make the list, I figured that either one of those languages would be more popular than Perl for web development today

Re:How does a language remediate anything? (1)

Unknown Lamer (78415) | about 4 months ago | (#46760353)

It is actually possible for the language to prevent certain classes of vulnerabilities. See Ur/Web [impredicative.com] . That's not what Perl is doing, but...

Re:How does a language remediate anything? (1)

lcfactor (786787) | about 4 months ago | (#46760803)

As for Ruby and Python - I'm particularly surprised they didn't make the list but ColdFusion did. I know of many CF apps in legacy support and development, but for new work?

For the life of me.... (2)

Primate Pete (2773471) | about 4 months ago | (#46760375)

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.

That Language Doesn't Exist (Yet) (0)

Anonymous Coward | about 4 months ago | (#46760389)

Real-time, embedded safety-critical software needs to be written in a well-specified language. It needs to be compiled and linked in well-validated tools (validated against the well-specified standard). It needs to be verified while executing on a target that was subject to the tools' validation.

The Ada language has too much conceptual baggage for compiler vendors and application developers to handle.. So, industry uses C, and increasingly C++, to get the work done. MISRA rules attempt to impose sanity, but MISRA rather expresses contempt for these languages. MISRA does not trust the compiler vendors nor the application developers, and the problem starts with the language specifications themselves. Ultimately, MISRA is a shame because it does not provide a means to validate the tools (neither the compilers nor the rules checkers).

We need a new language, one defined by subject matter experts, one that the industry can and will embrace. That language shall be called, "Blaz" (unwavering protector).

We've already been through this (1)

quietwalker (969769) | about 4 months ago | (#46760411)

A pretty comprehensive study was done that showed regardless of the language selected, the programs written by developers with the most experience in that language were the the ones with the least security bugs, regardless of traits of the language like attack surfaces or complexity.

It's short and sweet. A developer's experience with the specific language or framework an application is written in is a better indicator of application security than the language or framework an application is written in.

SQL and amalgamations (1)

istartedi (132515) | about 4 months ago | (#46760473)

SQL and amalgamations of languages (e.g., JavaScript generated by PHP) not on the list. XSS attacks involve such "mutt" software.

IMHO, the more code the more opportunities to exploit things. Terse languages to the rescue? Write it all in Haskell, Lisp or something. You'll attract talented developers and the attackers will be like... "Oh crap, we have to analyze that???".

No silver bullets of course. Something has to be able to read/write sensitive information at some point. Something has to determine under what conditions that occurs. It's human nature to make those conditions complicated to the point where vulnerabilities occur...

The real cause of Heartbleed (1)

SpaceLifeForm (228190) | about 4 months ago | (#46760593)

Was a new feature that was enabled by default. The heartbeat 'feature' should have been *DISABLED* by default. New features should always be disabled, and then you let the developer decide whether to enable it or not. And then *TEST* it! And *CODE REVIEW* it!

thisU FP f0r GNAA (-1)

Anonymous Coward | about 4 months ago | (#46760619)

FreeBSD is already become an unwa8ted never heeded the reaper BSD's

SQL injection attacks? (0)

Anonymous Coward | about 4 months ago | (#46761223)

People are still writing code vulnerable to SQL injection attacks?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>