Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Security

The Security of Popular Programming Languages 189

Posted by Soulskill from the new-ways-to-argue-about-your-favorite-language dept.
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."
This discussion has been archived. No new comments can be posted.

The Security of Popular Programming Languages More

The Security of Popular Programming Languages

Comments Filter:

  • Wonder how Ada 2012 would fare... (Score:5, Interesting)

    by mlts ( 1038732 ) on Tuesday April 15, 2014 @02:04PM (#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: (Score:2)

      by jythie ( 914043 )
      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.
    • It is possible to create powerful sites generated in Ada. One popular option is the Ada Web Server ( http://www.adacore.com/aws [adacore.com] ) ( http://www.freshports.org/www/... [freshports.org] ), plus it's possible to create cgi and fast-cgi applications using various libraries.

  • ASP? (Score:5, Insightful)

    by BaronAaron ( 658646 ) on Tuesday April 15, 2014 @02:14PM (#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.

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

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

    • 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 (Score:4, Insightful)

    by vux984 ( 928602 ) on Tuesday April 15, 2014 @02:14PM (#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 (Score:5, Interesting)

    by CastrTroy ( 595695 ) on Tuesday April 15, 2014 @02:16PM (#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 (Score:5, Funny)

      by jellomizer ( 103300 ) on Tuesday April 15, 2014 @02:27PM (#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 (Score:5, Insightful)

      by parkinglot777 ( 2563877 ) on Tuesday April 15, 2014 @02:45PM (#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

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

        • Re: (Score:2)

          by sjames ( 1099 )

          I thought about that a bit. It's easy to remove all but the functions intended to be used parameterized, but that doesn't prevent you from doing something stupid, it just doesn't invite you to be stupid. There is certainly something to be said for that.

          The solution for the second part would be a bit heavy weight and never really satisfactory. For example:

          "SELECT info from STUFF where id=$uid;"

          Pretty much anyone would agree that uid should be parameterized. However, what about:

          "SELECT $field from $table

    • It may be cliche, but how secure a language is depends on who is using it.

      Well, this might be one of those times where "correlation is not causation" is appropriate. What I mean by this is that while the skill of the user certainly matters, so does the quality of the tool. "It's a poor workman who blames his tools" is a warning against poor workmen, not a carte blanche for shitty tools.

      So of course, a tool can both help you and hinder you doing what you need to. It's no accident that you see top sportsmen obsessing over their equipment. Or why people don't clamour for manual gear

  • Mean number of vulnerabilities is a good metric? (Score:4, Insightful)

    by 140Mandak262Jamuna ( 970587 ) on Tuesday April 15, 2014 @02:18PM (#46759969) Journal
    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.

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

  • Not a useful paper (Score:5, Insightful)

    by MobyDisk ( 75490 ) on Tuesday April 15, 2014 @02:22PM (#46760007) Homepage

    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.

    • Re: (Score:2)

      by hAckz0r ( 989977 )
      I think 'slot' is a misinterpretation of someone else's pronunciation of SLOC, or source lines of code, but its usually used in (kilo) k-sloc or (mega) m-sloc when talking about errors in software. if you are talking about just sloc you are in deep trouble bug wise.

      .
      Another possibility is in GUI programming there is a such thing as a slot, which is essentially a callback routine associated with an interface control. However applying that definition to an error count metric is troubling since there is no

  • It's not just the language, but the implementation (Score:4, Insightful)

    by davidwr ( 791652 ) on Tuesday April 15, 2014 @02:23PM (#46760015) Homepage Journal

    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.

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

    • Re: (Score:2)

      by Shados ( 741919 )

      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 a

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

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

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

  • 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 (Score:5, Insightful)

    by gweihir ( 88907 ) on Tuesday April 15, 2014 @02:38PM (#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: (Score:2)

      by EvanED ( 569694 )

      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: (Score:2)

        by Arker ( 91948 )
        "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 th

    • Re: (Score:3)

      by naasking ( 94116 )

      The security level of a piece of code with good security is 95% coder competence and 5% language, i.e. language is irrelevant.

      Sure, and memory management, and program correctness, and just about any other achievable program property is 95% coder competence and 5% language by this argument. Except the coders that can guarantee 100% that said property is achieved make up 0.001% of the coder population, which means the vast majority of importance falls on the language to prevent memory leaks, out of bounds err

  • APL (Score:2)

    by stox ( 131684 )

    Not a single security exploit reported in over 50 years.

    • Re: (Score:2)

      by bazmail ( 764941 )
      Is anyone looking?

    • Re: (Score:2)

      by Misagon ( 1135 )

      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.

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

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

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

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

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

  • 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!
  • "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"

    How about designing a language that can't read/write past a previously allocated buffer in memory.
  • Do the work yourself and make your programs secure. C und ASM are Still the kings of the hill and always will be.

  • If you don't like C++ (and who does?) or C, what DO you suggest as a systems programming language?

    Rule 1: If it runs under a VM, it's out
    Rule 2: If it requires a garbage collector, it's out.
    Rule 3: COBOL and FORTRAN are out too.

  • what bash?
    yes sure. just stay away from eval
    I'm currently checking if other constructs from bash are prone to execution or information disclosure. Came across 'declare' which may have an issue.
    Of course, SQL injections are possible, because SQL is not bash.

  • its pretty much the case that programming languages in which it is harder to make bugs are also harder to make security problems. Because security problems are just a special case of bugs. So all the things we know about writing better languages are important for security. Unfortunately, language technology has always been under-appreciated. People will just use what is popular, which often times is just C or Java and so forth.

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close