×

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!

Choice of Programming Language Doesn't Matter For Security

Soulskill posted more than 3 years ago | from the obvious-things-your-boss-doesn't-understand dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

192 comments

Duh (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32130964)

This is because all of these web languages are implemented in C which is THE most insecure language ever designed.

Re:Duh (2, Interesting)

K. S. Kyosuke (729550) | more than 3 years ago | (#32131028)

I'm afraid it's you who is insecure, not C...

Re:Duh (1, Informative)

Anonymous Coward | more than 3 years ago | (#32131204)

True.

A system without any users is secure.

Re:Duh (1)

balbus000 (1793324) | more than 3 years ago | (#32131222)

C...

Oh cool, is C ellipses the new C sharp?

Re:Duh (1, Funny)

blair1q (305137) | more than 3 years ago | (#32131350)

>Oh cool, is C ellipsis the new C sharp?

No, C... is secure and C# is not.

Re:Duh (0)

Anonymous Coward | more than 3 years ago | (#32131424)

joke, fail. you can pretend that you made a joke in response, but its just not funny

Re:Duh (0)

Anonymous Coward | more than 3 years ago | (#32132552)

I agree that it's not very funny, but it's pretty obvious that it was intended as a joke.

Re:Duh (1)

WrongSizeGlass (838941) | more than 3 years ago | (#32131384)

C...

Oh cool, is C ellipses the new C sharp?

No, it's just another form of object notation in the next version of Objective-C. sigh ...

Re:Duh (4, Insightful)

Anonymous Coward | more than 3 years ago | (#32131242)

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:Duh (1)

aBaldrich (1692238) | more than 3 years ago | (#32131650)

You can overflow your buffers, dereference null pointers and anything you want. But, hey, if you are a good programmer you know how to avoid them. And if you are not a good programmer then it does not matter what language you use.

Re:Duh (0)

Anonymous Coward | more than 3 years ago | (#32131708)

Well; perhaps if you NEVER make a mistake. NEVER modify other peoples code.
NEVER get any work done...

Re:Duh (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32132080)

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:Duh (1)

Michael Kristopeit (1751814) | more than 3 years ago | (#32132222)

because when you tell the computer to dereference a pointer, it should do just that. you didn't tell it to check if the pointer was null first... that would take more time you might not have, and other code might have already ensured the pointer would not be null.

when developing real-time systems, using a language riddled with unnecessary error checking is not an option.

what i'm having a problem with is the existence of your question... do you really not understand the value of efficiency?

Re:Duh (4, Insightful)

Hurricane78 (562437) | more than 3 years ago | (#32132278)

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 (1)

Twinbee (767046) | more than 3 years ago | (#32132776)

It's dumb. Like those people re-implementing standard library functions. It's unprofessional and inefficient.

I thought that too until I found the bottleneck that is converting from float to int using (int) casting. I found the following to be multiple times faster:

unsigned floatToInt(double d)
{
        d += 4503599627370496.0; // 1 52
        return (unsigned &)d;
}

Re:Duh (1)

Hurricane78 (562437) | more than 3 years ago | (#32132548)

You got a nice statement there. Care to back it up with some actual arguments? You know:

I'm afraid it's you who is insecure, not C, because...

Re:Duh (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#32131142)

The purpose of C is to allow developers to develop close to the bare metal hardware - one step above hand-writing assembly code. Blame yourself for writing insecure code in C, not the C language itself. You fall on the -3 sigma side of the intelligence bell curve, don't you?

Re:Duh (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32131352)

Cool story, brah, but no im not a nigger like you

It's a good point but... (2, Informative)

SuperKendall (25149) | more than 3 years ago | (#32130968)

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.

Re:It's a good point but... (4, Funny)

Anonymous Coward | more than 3 years ago | (#32131182)

But I dare you to write a more secure web service in , than in Java.

I didn't know Whitespace [wikipedia.org] supported web services.

Of course it does (4, Funny)

SuperKendall (25149) | more than 3 years ago | (#32131684)

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... :-)

Re:It's a good point but... (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#32131546)

Java? Look, just because you code-by-number with the moron's toy programming language of choice, doesn't mean you're getting more secure programs. It's probably less secure because you Java douche bags can't code anyways.

Re:It's a good point but... (0)

Anonymous Coward | more than 3 years ago | (#32131612)

That was one of the funniest things I've read on this site in a long time.

Re:It's a good point but... (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32131726)

lol, sounds like someone wrote something in a language other than Java and got owned.

Bitter much?

Oh say can you C (1)

SuperKendall (25149) | more than 3 years ago | (#32131604)

Don't know where it went, but there was supposed to be a "C" in there and I swear there was one when I hit submit...

As it is though, I guess you can fill in your least favorite language!

Re:Oh say can you C (1)

K. S. Kyosuke (729550) | more than 3 years ago | (#32131792)

Don't know where it went, but there was supposed to be a "C" in there and I swear there was one when I hit submit...

Between pressing 'S-c' and 'Enter', you had a race condition.

Re:It's a good point but... (2, Insightful)

phantomfive (622387) | more than 3 years ago | (#32132068)

I've been thinking about this. Is Java really more secure than C? It is a harder question than it seems at first sight.

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:It's a good point but... (1)

binarylarry (1338699) | more than 3 years ago | (#32132272)

You fail it.

If you're worried about security, you don't assume a best case scenario. "lalala, ladee dah, I'll just make sure my C code is perfect with no exploits and it'll be just as secure as Java."

The reality is it only takes one simple, hard to find and debug fuck up and your application will be owned. In the same scenario using Java, the app would still be secure.

In a perfect world, C and Java are just as secure as one another. In reality, it's not even comparable, Java wins hands down.

Obviously... (1, Interesting)

Meshach (578918) | more than 3 years ago | (#32131076)

That seems like a no brain statement. It doesn't matter what language I use if I write insecure code the application will be insecure.

More at 11

I have an hypotheses (5, Insightful)

aBaldrich (1692238) | more than 3 years ago | (#32131080)

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.

Re:I have an hypotheses (2, Funny)

ClosedSource (238333) | more than 3 years ago | (#32131746)

The problem is that the set of all haskell applications is too small to be statistically significant. OK, I'm just kidding.

Re:I have an hypotheses (1)

blair1q (305137) | more than 3 years ago | (#32131752)

I think the opposite because the better programmer will be rendered an average programmer by the difficulties of the language.

Perl most secure (5, Funny)

by (1706743) (1706744) | more than 3 years ago | (#32131098)

'Cause even if the source is available, the would-be attacker won't be able to understand it [wikipedia.org]!

Re:Perl most secure (0)

Monkeedude1212 (1560403) | more than 3 years ago | (#32131776)

Security through Obscurity has always worked for Linux Distros.

(before you hit flamebait, I cast Mana shield! Only my Kharma points take damage)

Re:Perl most secure (1)

oldhack (1037484) | more than 3 years ago | (#32132792)

You under-mis-estimate Perl.

There once was a theory that undecidable problems are, well, undecidable and assumed to be unsolvable.

With the advent of Perl, not so. Undecidable, decidable, it's all just meaningless semantic bullshit before the mighty Perl interpreter - it is whatever she decides it to be, and she makes it so.

Its not black & white (5, Insightful)

Anonymous Coward | more than 3 years ago | (#32131104)

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:Its not black & white (2, Insightful)

phantomfive (622387) | more than 3 years ago | (#32131388)

Wow, way to let your pre-existing ideas blind you to the truth. Do you realize these guys are doing the scientific thing here, and testing assumptions like the one you just made? They made a statistical analysis of 1,700 websites in different languages. Do you think you could at least read their assessment before spouting off your rage? If you have a problem with their study, you should point it out. If you disagree with them because of what you 'think', you might as well start a church and call it a religion, because that is what you are practicing.

Re:Its not black & white (5, Insightful)

Fnkmaster (89084) | more than 3 years ago | (#32131706)

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 (1)

phantomfive (622387) | more than 3 years ago | (#32132194)

Good. You are criticizing the study. That is reasonable. The OP was not. The OP was spouting off his opinion without anything to back it up. If you can't see the difference, you're in trouble.

Re:Its not black & white (3, Insightful)

hibiki_r (649814) | more than 3 years ago | (#32131720)

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.

Re:Its not black & white (1)

alan_dershowitz (586542) | more than 3 years ago | (#32131732)

I think you're right to say that it's better to trust empirical evidence than go on seemingly logical assumptions. However, to me it looks like the study is making a _business case_ that all the tested languages are likely to produce roughly the same number of flaws. That is to say, as a business decision the programming language viewed by itself is not a significant factor. However I don't think it can be extended out to saying the language doesn't matter. It's not accounting for quality of programmer, design process, etc, those differences might be getting lost in averaging.

Like OP said, it seems logical that a language that simply has more exploitable metaphors and less secure alternatives should create more error prone software. I would like to see a study that compared say, JSP and C.

Re:Its not black & white (1)

gangien (151940) | more than 3 years ago | (#32131806)

I read the link, and since it requires registration of sorts to dl the pdf, I won't do that.

But it seems like a very macro level type of study, and that seems to gloss over technical details that you need when judging a language.

To use a car analogy, if you're measuring accident avoidance, and you note that the prius has the least amount of accidents, therefor it's the best for avoiding accidents. Ignoring the fact that what you're doing if your driving a prius, or the type of person that typically would use a prius. In otherwords the fact that it's a prius is probably fairly irrelevant.

Not that this type of study shouldn't be done, but just that it's hardly conclusive.

Re:Its not black & white (5, Insightful)

dgatwood (11270) | more than 3 years ago | (#32131814)

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:

  • Variable-length strings.
  • No truly fixed-size data structures or buffers.
  • No direct access to pointers.

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.

Re:Its not black & white (3, Informative)

bmajik (96670) | more than 3 years ago | (#32132084)

Well, the full paper is behind nag-ware, but here are the "top 3 findings"

Empirically, programming languages / frameworks do not have similar security postures when deployed in the field. They are shown to have moderately different vulnerabilities, with different frequency of occurrence, which are fixed in different amounts of time.

The size of a Web application's attack surface alone does not necessarily correlate to the volume and type of issues identified. For example Microsoft's .NET (ASPX) and Struts (DO), with near-average attack surfaces, turned in the two lowest historical vulnerability averages. ASPX and DO websites have had an average of 18.7 and 19.9 serious vulnerabilities respectively.

Perl (PL) had the highest average number of vulnerabilities found historically by a wide margin, at 44.8 per website and also the largest number currently at 11.8.ties have taken over 50 days to fix.

Gosh. To me that says that they found significant differences between the languages and platforms.

However, I am not ready to make any claims based on this, other than, they sampled a bunch of websites and then recorded information about vulnerabilities, and did "group by" on language/framework.

Isn't it likely that there is some selection bias here?

Rather than making claims about the intrinsic nature of some language or framework [like all of them are equal, or one is better than the others], don't you need to correct for the lack of control.. like same coders in the same organization trying to implement the same _type_ of application?

If I gave the same group of developers equal traning time, equal implementation time, and equal specs... and then said "do this in ASP.NET", and then "do it in Perl". And i did this with 10 groups of developers, and i changed the order of which application came first (i.e. some groups did perl first, some did asp.net first).

__then__ I would feel comfortable saying something about the relationship between language/framework and security vulnerabilities. What we really want to know is, given developers _like yours_, who've had equal training, expertise, and time, when trying to produce equivalent functionality.. how is _their_ production of security defects, and is there a difference between toolchains?

Now, I didn't read the PDF because if the nag-wall infront of it. But that doesn't sound like what they did here.

The goal out here in the real world is this: make an application that is secure-enough, cheaply-enough. "Cheaply-enough" means what caliber of people you need to hire, and how long it takes them to produce value-adding output. Secure enough means that the cost of fixing your bugs is higher than the cost of (risk of penetration * financial impact of penetration).

Re:Its not black & white (2, Insightful)

BitZtream (692029) | more than 3 years ago | (#32131390)

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:Its not black & white (0)

Anonymous Coward | more than 3 years ago | (#32131570)

Not true.

You list off the exploits from C then ignore all the other exploits of code out there.

For example is SQL exploitable? Many implementations are prone to exploits. Yet that is not a 'static' language by any means. In fact many would say it is entirely interpreted.

There are languages out there that 'hide' the details from you but all the things you list still exist. Can you tweak them or not depends on how good you are at it...

With a '4gl' language you have 2 things to attack instead of one. You have the runtime itself THEN the system it is running on. To say that it is impossible for say java to not be exploitable is short sighted. If it wasnt exploitable then there wouldnt be zillions of patches now would there?

Re:Its not black & white (4, Insightful)

dgatwood (11270) | more than 3 years ago | (#32131950)

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:Its not black & white (4, Insightful)

Delusion_ (56114) | more than 3 years ago | (#32131794)

"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 (2, Informative)

eulernet (1132389) | more than 3 years ago | (#32132342)

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.

You are totally wrong, since Javascript, which is interpreted, has numerous exploits involving stack crashing.
http://en.wikipedia.org/wiki/Heap_spraying [wikipedia.org]
with an example here:
http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit [stackoverflow.com]

ActionScript (from Flash) is also an interpreted language, and full of security bugs !

Re:Its not black & white (0)

Anonymous Coward | more than 3 years ago | (#32132734)

Your logic is system focused, in that you are worried about protected the host, not protecting what is hosted on it.

You don't need a buffer overflow to steal customer information if there is a simple logic flaw in the application.

Beat up any straw men lately? (1)

Seor Jojoba (519752) | more than 3 years ago | (#32131112)

"That aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages."

Whoever said, besides your 16-year-old cousin that just figured out how to add a flaming skull animation to his MySpace page, that there is any web application programming language that will guarantee security. Sheesh.

PHP and Visual Basic vs. Ruby, Python, etc. (0)

Weezul (52464) | more than 3 years ago | (#32131124)

I don't buy their argument, PHP and Visual Basic are famously bad at security, while most other languages require real work to achieve their innate level of insecurity.

sdfds sfgdfs dfg dsfg sdfg dfgdfg dfg sfg dfgfd dfgdg fdg dfsgljhf sdfgsdf gdflj sdfgdfg dgdf fglb4tsfgf

All garbage text posted towards the end of this message exists to compensate for how slashdot breaks safari's contextual menu for spelling correction.

Everybody hatin' on PHP (1)

jwietelmann (1220240) | more than 3 years ago | (#32131472)

PHP really is not that bad. Years ago it had a really horrible default configuration. But PHP, in my opinion, is viewed as worse at security than other scripting languages because it is more frequently used by people who have no business writing server-side code.

Re:Everybody hatin' on PHP (5, Insightful)

CastrTroy (595695) | more than 3 years ago | (#32131582)

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.

So... (0)

Anonymous Coward | more than 3 years ago | (#32131788)

In other words, for it to be non-secure you have to use deprecated features and be a novice. Which kind of proves the article's point.

Furthermore, you're perpetuating the myth that you can't write secure PHP or that writing secure PHP is difficult. In fact, you pretty much just prove the GP's point. PHP is perfectly fine, so long as the person who's writing it is not incompetant.

You wouldn't give a shotgun to a chimpanzee.

Re:Everybody hatin' on PHP (4, Informative)

wmbetts (1306001) | more than 3 years ago | (#32132436)

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 [php.net]

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 [php.net]

They are also planning on getting rid of the non-PDO db stuff at a future date.

Bloody hell... (2, Funny)

Anonymous Coward | more than 3 years ago | (#32131134)

You mean I am actually supposed to know what I'm doing?!

The Python Paradox (3, Informative)

calmofthestorm (1344385) | more than 3 years ago | (#32131224)

If you haven't heard of it, the python paradox is an interesting read: http://www.paulgraham.com/pypar.html [paulgraham.com]

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)

Re:The Python Paradox (5, Insightful)

barzok (26681) | more than 3 years ago | (#32131346)

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.

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:The Python Paradox (1)

Arthur Grumbine (1086397) | more than 3 years ago | (#32131670)

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.

Except gambling/poker.

Re:The Python Paradox (1)

swanzilla (1458281) | more than 3 years ago | (#32131748)

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.

I paid for my undergrad degree by landscaping, and I can say with some certainty that it is neither an interesting nor a fascinating subject.

You're oversimplifying (0)

Anonymous Coward | more than 3 years ago | (#32132002)

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.

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.

I'm going to have to disagree here. I have seen some code of a lot of crackpot geniuses in my time that was not worth a damn. Problem was, these guys were coding for the joy of it, but still working in a business environment. Which can turn out very badly when your programmer uses your very important application and its development as his personal programming playground. It's not that these people are bad programmers, but they are very often bad employees. Keep It Simple, Stupid has no meaning to them, and neither does pragmatism. When a programmer is coding just for the sheer joy of it, often the choices that bring them joy are not particularly useful or good for anyone else.

Re:The Python Paradox (2, Insightful)

tsalmark (1265778) | more than 3 years ago | (#32131646)

I think php is rather an interesting case. Looking at SQL injection: the language is strong enough and easy enough to protect against attack. Yet if you look at programming documentation, examples and free applets available on the web. Many of them have no protection at all. Also the forums providing answers to novice questions are often being answered by other novices. Best practices do not yet seem agreed on and pointed to in PHP as in other languages. So the bad practices are almost self perpetuating.

Re:The Python Paradox (4, Insightful)

calmofthestorm (1344385) | more than 3 years ago | (#32131698)

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:The Python Paradox (1)

ClosedSource (238333) | more than 3 years ago | (#32131842)

It's an interesting essay, but it's just speculation. Not any more insightful than the serious posts on Slashdot.

Turing-completeness isn't the point. (1)

SanityInAnarchy (655584) | more than 3 years ago | (#32131228)

Any language that lacks an inherent insecurity can be used to write secure apps, just as any language (Brainfuck, anyone?) can be used to write any program.*

You choose a language not because it makes it possible for you to do anything, but because it makes it easier than another language.

*I realize that there are cases where performance-per-core is critical, and that narrows your choices considerably. Still, in that situation, some use C, others use C++, and still others use Lisp.

Only web applications (1)

CastrTroy (595695) | more than 3 years ago | (#32131268)

I see the big problem here is that they are specifically talking about web applications. When you're doing web applications, the major security holes are SQL Injection, XSS attacks, HTML/Javascript Injection, and other such things. Nobody (almost) uses C for programming on the web. Of all the popular web languages PHP, .Net, Java, Python, and all the others, none of them use pointers, none of them require you to manage your own memory. This cuts out a lot of security exploits found in languages like C, in which the only thing left is other bugs like SQL injection. SQL injection is not something you can solve with a programming language. Unless your programming language didn't provide a way to run strings against the database, and only gave you access to the database through some object layer, like Hibernate or Linq, then there's nothing the language could do to stop stupid programmers from doing stupid things. There are constucts like prepared statements in all web programming languages, and there's no reason to have an insecure website, but the problem is, is that everyone wants a website, and doesn't want to pay qualified people to do the job. So they end up with insecure web sites.

Second idiotic article from 'WhiteHat Security' (0, Offtopic)

BitZtream (692029) | more than 3 years ago | (#32131272)

Seriously ... spamvertise/slashvertise much?

This is the second retarded WhiteHat story posted in the last hour and a half, how much are they paying you guys and how do I sign up? I have at least 2/3rds of a clue and I'm willing to pay for slashvertisements, that puts me well above any offer they could possibly make short of owning you outright.

OVERSOLD/HYPED: 'Web programming language' (3, Interesting)

david.emery (127135) | more than 3 years ago | (#32131406)

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.

Re:OVERSOLD/HYPED: 'Web programming language' (1)

hAckz0r (989977) | more than 3 years ago | (#32132062)

Agreed, I have yet to find a book on Web Programming in ADA, and I doubt if one ever did surface nobody would read it. Those features that make a language secure tend also to make it unpopular.

Re:OVERSOLD/HYPED: 'Web programming language' (1)

Hurricane78 (562437) | more than 3 years ago | (#32132088)

You forgot the functional programming languages, like Haskell, Ocaml, standard ML, Erlang, etc.
They usually have a track record of higher security without loss in performance (that Java has), since the checks can happen at compile time.

Of course you can still mess up things even in Haskell. E.g. [0,1,2,3,4,5]!!10 will cause a runtime exception. But the functions that can cause errors are well-known and can be avoided. Also, QuickCheck is a really great tool to test out all the possibilities.
If I ever had a heat-lung machine attached, I would want it to be written in Haskell. But never ever C, C++, or similar languages. Ever.

Re:OVERSOLD/HYPED: 'Web programming language' (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32132102)

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.

I'm secure (1)

SnarfQuest (469614) | more than 3 years ago | (#32131414)

I've been using intercal, and so far noone has comprimised my code.

Re:I'm secure (1)

dwinks616 (1536791) | more than 3 years ago | (#32132204)

I'm afraid you are mistaken. Someone obviously hacked your code and caused your computer to remove the space between "no" and "one." Either that, or you know someone whose name is "Noone" which is an odd name indeed.

Steve Ciarcia on programming languages: (2, Funny)

ctrl-alt-canc (977108) | more than 3 years ago | (#32131426)

"My favourite programming language is a soldering iron".

Re:Steve Ciarcia on programming languages: (1)

micheas (231635) | more than 3 years ago | (#32131934)

Reminds me of one of my roommates in college.

He had a poster of the saying (IIRC) "real programmers don't use operating systems they write directly on the hardware as god intended."

Some truths are eternal (1)

overshoot (39700) | more than 3 years ago | (#32131456)

"You can write a FORTRAN program in any language."

If anyone knows who deserves the credit for that one, BTW ...

Re:Some truths are eternal (1, Informative)

Anonymous Coward | more than 3 years ago | (#32131686)

The exact quote is: "Besides, the determined Real Programmer can write Fortran programs in any language." It comes from a letter to the editor titled "Real Programmers Don't Use Pascal," attributed to an Ed Post.

Link. [pbm.com]

Java (2, Insightful)

caluml (551744) | more than 3 years ago | (#32131742)

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.

dictionary.com? (0)

Anonymous Coward | more than 3 years ago | (#32131786)

Wah, I am the worst programming language in the world, I am so insecure! Nobody loves me. Nobody cares about me. I can't do anything right. If only I were nonsecure instead.

A poor craftsman blames his tools (2, Insightful)

CoffeeDog (1774202) | more than 3 years ago | (#32131826)

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.

False dichotomy much? (1)

Hurricane78 (562437) | more than 3 years ago | (#32131892)

There isn’t just “secure” and “not secure”, you know? Some are more and others less secure.

And I have only one thing to say:

Haskell > Java > C :)

(Java has built-in checks that prevent the worst errors of C. And Haskell also has them, but at compile time, so you get back the performance. Of course those language are just examples, and any similar languages could be placed in there instead.)

Re:False dichotomy much? (2, Insightful)

binarylarry (1338699) | more than 3 years ago | (#32132170)

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.

Wow... (0)

Anonymous Coward | more than 3 years ago | (#32131958)

You mean that application security is mainly affected by the person writing the code? Who could have predicted THAT one?

What a dumb point... (0)

Anonymous Coward | more than 3 years ago | (#32132138)

Sure, security is a matter of good coding habits. It still doesn't matter how good your habits are if the tools you use are insecure. Yes, PHP I mean you!

This is absurd. (1)

Maltheus (248271) | more than 3 years ago | (#32132640)

Sure, if you take extra precautions with the buffer-overflow languages, your software can be just a secure. But in the real world, that's almost never the case. Projects are always rushed and mistakes happen. Every team has one or more weak links. And what coder prefers burdensome process to development anyway? Anyone who promotes C/C++ over Java for a back-end enterprise application is not a professional IMO. They come across as stubborn basement hackers who can't keep their resumes up to date. C/C++ was never much more than a macro assembly language, and like assembly, not appropriate for most (non-single-person-genius) projects.

But who provides the language implementation DOES (1)

khb (266593) | more than 3 years ago | (#32132692)

http://www.c-program.com/kt/reflections-on-trusting.html [c-program.com] is worth another read. Apple can make a reasonable case that allowing other development tools in their little garden reduces their ability to ensure a secure system.

I concur with posters who observe that some languages do have more protections than others; but in the end the application programmer needs to be careful and security aware, and there has to be complete trust in every step of the processing from what the programmer writes to what is run on the device.

Now whether the loss of flexibility is worth having to trust only Apple is a reasonable policy question; but I can see why Apple might want to be draconian about this.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...