Slashdot Mirror


Choice of Programming Language Doesn't Matter For Security

An anonymous reader writes "The Security Ninja has written a blog post which discusses web programming languages and the fact that they are all insecure. It's based on a report from WhiteHat Security and aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages. '... secure code is the product of a secure development process and real business commitment to deliver secure applications which includes developer education. The absence of these processes and business commitments will lead to web applications being developed insecurely regardless of the language being used.'"

23 of 192 comments (clear)

  1. I have an hypotheses by aBaldrich · · Score: 5, Insightful

    I think that in average programs written in haskell (exempli gratia) tend to be more secure because it takes a better programmer to write them than a quick and dirty VB application.

    --
    In soviet russia the government regulates the companies.
  2. Perl most secure by by+(1706743) · · Score: 5, Funny

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

    1. Re:Perl most secure by crow_t_robot · · Score: 3, Informative

      Perl is terrible but Malebolge takes the cake: http://en.wikipedia.org/wiki/Malboge_(programming_language) Enjoy your brain exploding.

  3. Its not black & white by Anonymous Coward · · Score: 5, Insightful

    Anyone who says all programming languages are equally exploitable is a fool. Sure, secure coding practices and standards are the way to approach the issue- not language selection, but it is, for instance, impossible to overrun a buffer in interpreted byte code and executed native code. The fact that stack crashing doesn't exist in interpreted code alone demonstrates that languages (or their runtime environments that are inherent to a language) are not all equal in exploit-ability levels. To say they are all the same is simplifying things too much. Yes, all languages have their exploitable bad practices, but some have more than others.

    1. Re:Its not black & white by Fnkmaster · · Score: 5, Insightful

      Yeah, except this isn't a comparison by language. It's a comparison by platform technology. For example, JSP shows as one of the highest vulnerability ratios, whereas Struts (Apache's Java MVC framework) has just about the lowest vulnerability ratio (on par with ASPX).

      Clearly they are measuring *something* but it seems to have relatively little to do with languages themselves.

      If anything, it seems like web apps written in frameworks that don't actively discourage mixing code and presentation are more likely to have vulnerabilities, whereas frameworks that encourage separation more actively (and perhaps are newer frameworks) are less likely to have vulnerabilities. The worst two measured, Perl and JSP, are older technologies that date from the era before frameworks that enforced more MVC separation were common and before web app best practices really existed.

    2. Re:Its not black & white by hibiki_r · · Score: 3, Insightful

      The test itself already has bias, precisely because it works on a family of programs that happen to have a very limited set of inputs, and where the avenues of attack are relatively limited in some very important ways. The core vulnerabilities of websites have been done to death, so at this point, barring utter stupidity, I'd have been surprised if the security problems were noticeably different depending on the language.

    3. Re:Its not black & white by Delusion_ · · Score: 4, Insightful

      "All languages are exploitable" != "all languages are equally exploitable".

      You're the first person to bring the word "equally" into the conversation, and have missed the point.

    4. Re:Its not black & white by dgatwood · · Score: 5, Insightful

      They made a statistical analysis of web languages. That's not generalizable to all programming languages as the Slashdot headline implies. All of these languages have several things in common:

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

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    5. Re:Its not black & white by dgatwood · · Score: 4, Insightful

      The difference is that flaws in the Java runtime (or any runtime) are A. infrequent, B. somebody else's fault, C. quickly fixed once discovered, and D. not specific to your individual installation. Thus, as long as you pay attention to the security notices, you're probably fine.

      Put another way, there are thousands of people looking for flaws in the Java runtime. When you're talking about flaws in your code, the only people looking for bugs in it are you and the bad guys. This means that it is much more problematic to have 1,000 bugs in your code than to have 1,000 bugs in the Java runtime. With the latter, the odds are in your favor that the flaws will be first discovered against somebody else's website. WIth the former, the only place those flaws can be discovered is on your website.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    6. Re:Its not black & white by bmajik · · Score: 3, Informative

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

      --
      My opinions are my own, and do not necessarily represent those of my employer.
  4. Re:It's a good point but... by Anonymous Coward · · Score: 4, Funny

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

    I didn't know Whitespace supported web services.

  5. Re:Duh by tool462 · · Score: 3, Funny

    Careful. You might get him so mad that he'll have a buffer overflow and then core dump.

  6. The Python Paradox by calmofthestorm · · Score: 3, Informative

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

    Simply put, the kind of people who learn a language out of interest than out of wanting to get a job tend to be better programmers on average. (This was written awhile ago, when Python had little use outside the FOSS community. Now that Python is looking like it may someday replace Java, perhaps the Haskell Paradox is a better term).

    Anyway, perhaps the same issue is at play here. Perhaps the people who use PHP tend to be less aware of security or more apathetic toward it, and thus there is a two way feedback between language and programmer (the last time I used Visual Basic the compiler was as full of holes as a piece of swiss cheese and Microsoft wanted me to pay $100 each to report counterexample bugs, but that was 6.0, back in middle school)

    --
    93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
    1. Re:The Python Paradox by barzok · · Score: 5, Insightful

      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.

    2. Re:The Python Paradox by calmofthestorm · · Score: 4, Insightful

      Exactly. The culture of a language is as or more important than the language itself. Indeed, the culture shapes the language (but of course, to a degree, the language shapes the culture).

      Java itself isn't a very good language, but it's the hordes of incompetent Java programmers who make it such a terrible choice for everything. This goes back to the Python paradox: companies want Python programmers to write Java for them.

      I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest, and where the dumbest can't write code that does too much damage.

      --
      93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
  7. Re:Duh by Anonymous Coward · · Score: 4, Insightful

    Yeah cause a language that makes it trivially easy to overrun a buffer, dereference null pointers and smash the stack is clearly a highly secure language. Oh wait...

  8. OVERSOLD/HYPED: 'Web programming language' by david.emery · · Score: 3, Interesting

    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.

  9. Re:Everybody hatin' on PHP by CastrTroy · · Score: 5, Insightful

    PHP really is that bad. Because they still haven't removed the cruft. If they were really serious about any kind of security, they would have gotten rid of magic quotes completely, as well as things like mysql_escape_string. Instead they left these gaping security holes in there, for the sake of compatibility. Meanwhile you have a bunch of cheap web hosts who turn things like magic quotes on by default, thinking it will solve all their customers' security problems, when really it just extends the problem by leading them down the wrong path. While they've added things (MySQLi/PDO for prepared statements, mysql_real_escape_string, and others) the amount of legacy stuff they left in there is amazing, and for a language with so many novices working with it, ends up being a real disaster.

    --

    Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
  10. Of course it does by SuperKendall · · Score: 4, Funny

    I didn't know Whitespace supported web services.

    Sure it does, I had a full shopping cart system at the end of my post by way of example.

    Prove me wrong... :-)

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  11. Re:Duh by Hurricane78 · · Score: 4, Insightful

    Ye Olde Excuse: “you’re just not good enough”

    You know, in modern languages, you can once abstract that concept out that you don’t want buffer overflows and dereference null pointers, and you’re done.
    In C, you have to re-invent the wheel again and again and do the same micromanagement over and over. It’s like the man with three buttocks on Monty Python: We’ve done that! We’ve solved it. We have nice standardized solutions. (Java doing runtime checks by default. And Haskell doing them at compile time.) Use them!

    With modern languages, you can use your mental resources to tackle the actual problem, instead of having to constantly think about decades old and long solved problems that should long be included by default.
    And the biggest joke is, that most C programmers manually implement those systems themselves, and then act all proud, because they re-invented the wheel, except that it never received the literally decades of testing of the well-studied existing solutions.

    It’s dumb. Like those people re-implementing standard library functions. It’s unprofessional and inefficient. And very error-prone for no reason at all.

    --
    Any sufficiently advanced intelligence is indistinguishable from stupidity.
  12. Re:Everybody hatin' on PHP by wmbetts · · Score: 4, Informative

    Changes in PHP 6
    Issue: Register globals are the source of many application's security problems and cause a constant grief.

    Discussion: We shortly discussed how we want to attend users on the disappearance of this functionality. We decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and some introduction on safe programming.

    Conclusions:

    We are going to remove the functionality.
    We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting

    http://www.php.net/~derick/meeting-notes.html#id12

    Issue: Magic_quotes can be cumbersome for application developers as it is a setting that can be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts.

    Discussion: In the same way as with the remove of the register_globals functionality, we decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and point the users at the input_filter extension as replacement.

    Conclusions:

    We remove the magic_quotes feature from PHP.
    We throw an E_CORE_ERROR when starting PHP and when we detect the magic_quotes, magic_quotes_sybase or magic_quotes_gpc setting.

    http://www.php.net/~derick/meeting-notes.html#id13

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

    --
    "Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
  13. Re:Duh by Tyler+Durden · · Score: 3, Insightful

    There are still tasks that are better suited for languages like C and C++. The interesting ones. The alternatives?

    "You mean I get to build another boring business web application using the latest kludgy framework du jour so that it's obsolete two weeks later when the more popular kludgy framework comes out. Oh boy!" (OK, it's a little bit better than that. But not much. :) )

    Games development, systems development, OS development, embedded programming and the like are places where it pays for development to be done by people who know what they're doing using tried and true programming tools that demand such expertise. When did Slashdot become so dull that nobody was interested in this stuff anymore?

    --
    Happy people make bad consumers.
  14. Re:It's a good point but... by dotgain · · Score: 5, Insightful

    For example, a buffer overrun in a desktop app (excel, photoshop, whatever) is not a security breach, it's just annoying.

    Bad choice of examples. That's what we were saying and thinking in 1998: IT to PHB: "Don't open any EXE files mailed to you, however Excel spreadsheets, Word docs etc, are fine".

    A exploitable buffer overrun in any application where malicious inputs exist is a security hole.