Slashdot Mirror


The Top Programming Languages That Spawn the Most Security Bugs (softpedia.com)

An anonymous reader writes: Veracode has put together a report after static analysis of over 200,000 apps, and its results show that Classic ASP, ColdFusion, and PHP generated the most security bugs in scanned applications. Ignoring the first two, which are almost extinct languages, PHP, used for Drupal, Joomla, and WordPress (which recently announced it runs a quarter of the Internet) is the programming language with the most security woes.

6 of 241 comments (clear)

  1. Re:What's a "programming language"? by tjarrett · · Score: 5, Informative

    I'm an author of this report, so thought I'd offer some feedback.

    First, the iOS applications that Veracode scans are written in Objective C (and probably some C or C++). And the Android apps are written in Java. (Yes, you can write iOS and Android apps using portability frameworks like PhoneGap; we separate those findings out into a separate category.) We used iOS and Android as shorthand so that (a) readers would more readily make the connection with what ObjectiveC meant, and (b) we could separate Java used in Android, which has a distinctive risk landscape, from Java used in other applications.

    Second, we choose to report on application prevalence, or the number of applications showing at least one of the vulnerability, rather than number of vulnerability occurrences. The application prevalence metric is more meaningful when talking about the overall risk of a large number of applications. There is value in the vulnerability prevalence metric, when it comes to planning remediation effort, but for this study we focused on the former.

    Third, we do report average flaw density metrics in the appendix of the study, along with a discussion of some of the limitations of this metric. I suggest reviewing the actual study (it's only about 20 pages) and then posting any additional questions.

    Thanks for the questions and keep them coming.

  2. Re:What's a "programming language"? by Rei · · Score: 3, Informative

    They use labels like "Objective C (iOS)", which the article is just shortening to "iOS". Also they report errors as "number of errors per megabyte of source code".

    Wish they'd broken down C and C++, they're very different languages in terms of how people typically develop them (non-automated vs. automated memory management). Instead they grouped them together and called them just "C++".

    Sad that injection bugs are still so prevalent. Kind of makes me wish that standards for different languages would refuse to accept normal strings as arguments to anything that "executes a statement" (SQL, shell commands, etc), and instead require a custom command-string type/class which does not allow straightforward concatenation (making developers explicitly have to convert types if they want to concatenate, maybe with a conversion function name like "useUntrustedString" or somesuch), with the error message if they try to concatenate without explicit conversion pointing out not just that concatenation is banned, but stating why it's banned. Maybe something like that would finally get people to start using proper parameter substitution...

    --
    I hate to bring up our imminent arrest during your crazy time, but we gotta move.
  3. Re:Meaningless conclusion. by phantomfive · · Score: 4, Informative

    Something like 75%-80% of the web runs on php (Wordpress, for example.) Naturally if you examine a large number of sites, most of which run on php, you're going to see more security problems coming from sites that run on php.

    Seriously man? You don't think the researchers thought of that? If you had even clicked on the article, you would know that they did.

    In any case, here is the full list:

    Classic ASP - with 1,686 flaws/MB (1,112 critical flaws/MB)
    ColdFusion - with 262 flaws/MB (227 critical flaws/MB)
    PHP - with 184 flaws/MB (47 critical flaws/MB)
    Java - with 51 flaws/MB (5.2 critical flaws/MB)
    .NET - with 32 flaws/MB (9.7 critical flaws/MB)
    C++ - with 26 flaws/MB (8.8 critical flaws/MB)
    iOS - with 23 flaws/MB (0.9 critical flaws/MB)
    Android - with 11 flaws/MB (0.4 critical flaws/MB)
    JavaScript - with 8 flaws/MB (0.09 critical flaws/MB)

    --
    "First they came for the slanderers and i said nothing."
  4. Re:The problem is not the language, it is the code by xxxJonBoyxxx · · Score: 5, Informative

    >> above will allow you to take the user entered name and put it into a SQL query without fear of little Bobby Tables wrecking havoc with your systems

    [FACEPALM/] That's not even "checking user input" (i.e., making sure the user submitted an expected response) - that's "mindless scrubbing of a single naughty character."

    Please send me a couple of the URLs where your apps live and I'll just go get the rest of I want from there.

  5. Re:Are all ten of them Java? by allcoolnameswheretak · · Score: 3, Informative

    Java actually compares favorably against C# and C++ when you rank it based on the number if critical flaws:

    1. Classic ASP - with 1,686 flaws/MB (1,112 critical flaws/MB)
    2. ColdFusion - with 262 flaws/MB (227 critical flaws/MB)
    3. PHP - with 184 flaws/MB (47 critical flaws/MB)
    4. .NET - with 32 flaws/MB (9.7 critical flaws/MB)
    5. C++ - with 26 flaws/MB (8.8 critical flaws/MB)
    6. Java - with 51 flaws/MB (5.2 critical flaws/MB)
    7. iOS - with 23 flaws/MB (0.9 critical flaws/MB)
    8. Android - with 11 flaws/MB (0.4 critical flaws/MB)
    9. JavaScript - with 8 flaws/MB (0.09 critical flaws/MB)

    I think there is something wrong with their test method, skewing the JavaScript results.

  6. Re:Are all ten of them Java? by tjarrett · · Score: 4, Informative

    An important clarification: as the report states, during the period from which this data was drawn, Veracode only supported analyzing mobile JavaScript applications (mobile applications built using cross-platform JavaScript based frameworks like Titanium and PhoneGap). Since this period we've added support for analyzing both JavaScript in the web client (e.g. JQuery based applications) and on the server (Node.js based applications), so the results should be interestingly different next time around. But this limited JavaScript support is a reason that we didn't seek to draw any broad conclusions based on the language in this study.