Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
PHP Bug Programming Security

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

Posted by Soulskill from the prepared-to-not-be-surprised dept.
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.
This discussion has been archived. No new comments can be posted.

The Top Programming Languages That Spawn the Most Security Bugs More

The Top Programming Languages That Spawn the Most Security Bugs

Comments Filter:

  • normalized? (Score:5, Insightful)

    by Anonymous Coward on Friday December 04, 2015 @10:27AM (#51056841)

    The Internet is a lot bigger now, so you'd expect more discovered PHP bugs than ColdFusion bugs.

    Coming up next, there are more operating systems written in C than Fortran, so you will find more root privilege escalations in C than Fortran.

  • Self-fulfilling prophecy? (Score:4, Insightful)

    by mindmaster064 ( 690036 ) on Friday December 04, 2015 @10:30AM (#51056869) Homepage
    It's pretty obvious the most common language is going to have the most apparent bugs and the most security woes because it is the one that is most used to solve the majority of problems. It also will be the most likely for hacker and bad people to be using as well as working to exploit as it is the language that they are most familiar with. Every language is going to have security issues it's what happens with the running application when it faults that matters, and that is likely within the control of the developers even when the language and library authors are contributing to the issues. Really, the number one "cause for exploits" is trusting input that shouldn't be trusted -- and that's that same problem for nearly any language... It has nothing to do with PHP!

    • Re:Self-fulfilling prophecy? (Score:5, Insightful)

      by paulpach ( 798828 ) on Friday December 04, 2015 @11:20AM (#51057249)

      There is more to it than simply being popular. Consider a case where you want to output data that the user posted in a form. The obvious way to do it in PHP is this:

      Hi <?php echo $_POST['name']; ?>.

      In fact up until a few years back, the php tutorial had code like this [archive.org].

      This is vulnerable code, the values posted may contain javascript, and the browser would execute it happily. If you are displaying content that other people posted, then a malicious user can easily exploit this code to hijack other users sessions. This is known as XSS (Cross site scripting), and it is one of the most common vulnerabilities in PHP code.

      The secure way is this:

      Hi <?php echo htmlspecialchars($_POST['name']); ?>.

      A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else. For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value. In the name of convenience PHP is plagued by questionable design decisions like this. register_globals was on by default up until php 4.2, it is incredibly easy to write sql injection vulnerabilities in php if you are not paying attention, etc.

      • Re: (Score:2)

        by tepples ( 727027 )

        For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value.

        Which would make it that much harder to use PHP to output a Content-type other than text/html or types matching application/*+xml.

      • The secure way is this:


        Hi <?php echo htmlspecialchars($_POST['name']); ?>.

        A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else.

        Could you give that example in C, C is normally considered a good language.

      • There's no actual security issue there. How can one client POST something and the response from that request go to a completely different client? They can't. And if the user's client machine is compromised to inject javascript in a post, well, um, what is the point of sending it to the server to have it send it straight back?

    • Re:Self-fulfilling prophecy? (Score:4)

      by hey! ( 33014 ) on Friday December 04, 2015 @11:57AM (#51057569) Homepage Journal

      While I strongly agree with the argument that PHP's large target footprint has something to do with its reputation for insecurity, I can't help but wonder whether the architectural similarities of typical PHP, ColdFusion and ASP.NET have something to do with the tendencies of some programmers to produce vulnerable code with them. If you squint, they all have a strong family resemblance to each other: you mix language-specific procedural markup with HTML, which is processed on a server and returned as plain HTML to the browser.

      Note that I'm not saying PHP is inherently insecure, but I can think of three reasons why this approach might tend to encourage insecure practices. The first is the way programmers, particularly novice programmers, tend to be introduced to such systems. This is a pet peeve of mine; instructors try to sell students on how easy it is to do things so they show students the simplest way of producing a particular result -- not the way that a proficient programmer should produce that result. The message is "look at how easy it is to make a dynamic website with X!" The details of what you need to do to do things like sanitizing input really clutter that message up; especially in the case of these template-y languages where one of the chief selling points is that they're incremental on top of the HTML you need to know anyway.

      It's interesting to contrast something like these systems to JSP, which can be used in exactly the same way except that programmers are taught early on that this "model 1" approach is for wimps who can't handle MVC. Java web apps tend to be grossly over-architected; PHP web apps -- at least the ones I've looked at -- tend to be under-architected, with lots of code replicated across many files which should be centralized in some kind of library. That's the second reason I can think why PHP apps might tend to be insecure: under-designed systems mean you have more places where you have to implement some design policy, or where a "temporary" bit of code that does something like build a SQL query from unchecked user input might slip through into production code. It's not the fault of the language per se; it's programmers reproducing the simplest way they were taught to do something over and over again rather than taking the time to refactor their work so that maintaining and securing it is a manageable task.

      The third reason I can think of is that these kinds of systems are so easy for someone who doesn't know what he's doing to tweak in the field. I've done it myself; if you have a basic knowledge of HTML, have ever used a programming language, and know how to use "grep" you can find the bit of PHP that produces a particular output and tweak it to your liking without being a PHP programmer. That means that code that ships secure might not remain so in the field.

      Anyhow, I don't know enough about PHP per se to say whether it is inherently insecure in some way, but what I've seen leads me to think that some of the problems at least may be an unwanted side effect of ease of use and learning. There's a world of difference between a PHP system generated by a skilled and conscientious programmer and someone who knows a little HTML and picks up a little PHP to add to that. Fortunately this kind of hacked-up HTML website is looking increasingly archaic these days; if you look at RESTful PHP code it looks pretty much like RESTful interfaces done in any other scripting language. It doesn't have the sprawl I tend to associate with PHP web apps.

      • Note that I'm not saying PHP is inherently insecure, but I can think of three reasons why this approach might tend to encourage insecure practices. The first is the way programmers, particularly novice programmers, tend to be introduced to such systems. This is a pet peeve of mine; instructors try to sell students on how easy it is to do things

        I can't speak for anyone else, but I can say that I got into developing webpages way before I knew anything about "proper" programming practice because it was easy. I was banging out CGI scripts in bourne script before I even knew how to do a good job of it, let alone why you wouldn't want to do it. The server wound up getting exploited through a remote hole in Apache long before any of my scripts could be a problem. Besides, they all ran as a relatively unprivileged user. Now I just use a CMS, and keep up

        • Re: (Score:2)

          by hey! ( 33014 )

          The server wound up getting exploited through a remote hole in Apache long before any of my scripts could be a problem. Besides, they all ran as a relatively unprivileged user.

          Well, in the early days that would likely have been the case; the vulnerabilities in the Apache server would have presented a better-known target than your code, people weren't in the habit of keeping up with security updates, and automated tools for attacking website specific code didn't exist yet. Today if you did that then flaws in your code would be much more likely to be the cause.

          I'm sure you know that the fact that your code runs unprivileged doesn't really protect you or your users, especially thes

  • Apps, it had to be apps (Score:2, Insightful)

    by Anonymous Coward

    That's the bigger problem than the limits of an individual language. The mindset of gluing together little bits of existent code to add serious functionality to what was originally intended as a static information display. Odds are the budget for these projects is tiny and the testing budget is zero. That last detail is what really matters, no dedicated testing, no time allotted for testing beyond 'does it work when the boss tries.'

    ASP, ColdFusion and PHP are only the top three because (despite two being

    • Re: (Score:2)

      by gweihir ( 88907 )

      If fully agree. The problem is incompetent and semi-competent people "quickly kludging new functionality into fairly simple web pages".

      • Personally, I wouldn't consider functional bugs to bugs in the language, unless there is no way to accomplish a task without generating exploitable bugs.

        Don't blame the result on the language, unless the language itself is the problem. SQL injections are not a programming language issue. It is a problem with the coders.

        • Personally, I wouldn't consider functional bugs to bugs in the language, unless there is no way to accomplish a task without generating exploitable bugs.

          The standard library has bugs. For example, one bug in PHP is the existence of mysql_escape_string, whose behavior is unlikely to match the quoting conventions set on the current connection except by coincidence. These bugs are kept for the sake of backward compatibility, even if they're exploitable by using an incorrect quoting convention for SQL injection.

          But it is a bug to fail to discourage new code from using deprecated library functionality. Failure to conspicuously mark deprecated functionality as su

    • Dammit...I've been defending ColdFusion on Slashdot for about 12 years (see username). The last 5 years or so have been very quiet as people just assumed CF was gone. Or more to the point, the 'my language is better than your language' people had moved on.

      I've been writing in CF for about 17 years. Yes, even today I use it...and I use it all day long. This is not just "quickly kludging new functionality into fairly simple web pages", it's a matter of creating entire line of business apps.

      Guess what? Pe

      • Re: (Score:3)

        by mikael ( 484 )

        "What's my point? I think that too many people in tech are enamored with the new/shiny and jump from technology to technology without spending enough time on the QUALITY of what they are creating"

        There are those people who just like to work on blue-sky projects where everything is new and there is no "legacy code". So they are the first to learn the latest skills, design basic systems, then move onto the next project. Everyone else has to clean up after them.

  • Good thing I'm still using Perl!

  • And that's surprising ... how? (Score:5, Insightful)

    by Opportunist ( 166417 ) on Friday December 04, 2015 @10:33AM (#51056897)

    Especially for PHP you will notice that it is the first, if not the only, language people pick up when dealing with scripting for web pages. ColdFusion always smelled a bit like a web designer tool to get some kinda-sorta interactivity into their designs rather than something a programmer would willingly pick up, and I don't know of anyone who seriously learned programming and didn't give ASP a wide berth.

    So what you have there is three languages that are predominantly used by people who cannot program sensibly.

    In other words, you are dealing with the usual woes of cargo cult programming and copy/paste code. Code and snippets, copied and gobbled up from whatever sources there are on the net, sample code and code Q&A pages that are slapped together and adjusted to fit the needs. Primary concern: It should work. Security? Doesn't even enter the picture. Not even as an afterthought.

    That this results in security bugs is a given.

    • >> ColdFusion always smelled

      Let me stop you right there. No, seriously, that pretty much sums it up.

    • I don't know of anyone who seriously learned programming and didn't give ASP a wide berth.

      It's worth noting that ASP isn't even a programming language. It's not a language at all; it's a set of conventions for integrating arbitrary scripting languages into your webserver. Out of the box you can use either vbscript or jscript, and you can also add other languages like perl. And then you can mix them all in a single document. The holes "caused by ASP" were just holes in IIS or in one of the script engines.

      I once worked for a company which did websites for bands, and one of the big projects was a m

  • What's a "programming language"? (Score:4, Interesting)

    by david.emery ( 127135 ) on Friday December 04, 2015 @10:35AM (#51056901)

    Are "iOS" or "Android" the same as "PHP" or "C++"? I didn't hand in my personal informatoin to get the full study, but the stuff shown on this story's link pegged my bs-meter. Also, I'd hope there's a discussion of 'number of occurrences,' finding 10 bugs, 8 of which are null pointer dereference, should be different from finding 10,000 bugs where 'only' 7,500 of them are null pointer dereference.

    And wouldn't it be even more useful to know which languages generate the least number of bugs, per line of code?

    • Re: (Score:2)

      by Tx ( 96709 )

      I was about to post exactly this; since when are Android, iOS or .net programming languages? And yeah, measuring flaws per MB of source code - surely there are pretty large differences in source code "density" (i.e. how many characters of source code it takes to get a job done) between the things which actually are programming languages, so that's not really a valid measurement IMO.

      • It must be great for Ada, though, because it so incredibly verbose.

        Also, just changing your C programs from K&R to GNU indentation style will make them more secure!

        • The normal metric for languages like Ada, Pascal and yes C or C++ (those should not be considered the same language!) is "statement" as defined by the grammar, and usually simplified by counting "semicolons". If you figure out how to add preprocessor/header files, you'll probably see that for equivalent applications, the statement count between C and Ada is about the same. That's based on my real-world experience working with both languages over the last 30 years, I have no idea if the parent poster has

          • I have no idea if the parent poster has much real experience in Ada (I kinda doubt it.)

            I have (sort of), because I have chosen Ada a long time ago as my main implementation language for things that need to be fast. But I'm only programming as a hobby and was joking. Anyway, I didn't want to imply that Ada is more verbose than C. They are both insanely verbose.

    • Re:What's a "programming language"? (Score:5, Informative)

      by tjarrett ( 162732 ) on Friday December 04, 2015 @10:53AM (#51057031) Homepage

      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.

      • Thanks for dropping in with the clarifications!

      • Re: (Score:2)

        by T.E.D. ( 34228 )

        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.

        I might. Got a link? There's no link to it that I could find either here or in any of the links on this story.

      • ok, here's a question.......

        Since Android is written in Java and C++, why (in your opinion) did Android get such a low bug count compared to Java and C++?

    • Re:What's a "programming language"? (Score:4, Informative)

      by Rei ( 128717 ) on Friday December 04, 2015 @10:53AM (#51057033) Homepage

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

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

        Say you want to write a SELECT statement in SQL, but you want to give the app's user options for what information is included in a report. These options may cause the statement to refer to different columns in the heading, or a JOIN to different tables, or different columns used for summary (GROUP BY). For these kinds of query adaptation, you can't use a prepared statement because the PDO API allows substituting only literal scalar values (such as 3 or 'kitten') into a prepared statement, not table names, n

      • Sad that injection bugs are still so prevalent

        Am I the only one who finds it strange that we still do DB access via SQL? How did it become normal to string together code for one language using another? Imagine every time we had to do math, it was via a weird language whose interface was entirely eval()-type operations.

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      Just realize that a null pointer dereference isn't necessarily a security issue, it's a potential security issue and it's a potential stability issue.

      If the application just bombs when you encounter it and returns a server error page once in a while then it's not a big deal, but if someone can feed the pointer data through a crafted request it's a different matter.

      Just use Valgrind and Splint and you will shoot most of the blatant errors. But there are still the area of not so obvious errors that are harder

  • Reason for this (Score:4, Interesting)

    by xxxJonBoyxxx ( 565205 ) on Friday December 04, 2015 @10:35AM (#51056911)

    If this was from a dynamic scanning company, I would have suspected these results would occurred because that code often run in environments often configured to show web users raw error output, such as "your database call failed - here's what I tried so you can tune your SQL injection attempt appropriately."

    [rant] In general, I've found that the utility of "dynamic" (or pentesting) web scanners has dropped precipitously lately as web apps have pushed their presentation out to Javascript apps (making it easier to probe a finite set of web services with standard testing and fuzzing tools) and almost all new environments are set to display terse "got error - now fuck off" messages to end users (if not just a redirect back to the app's home page) if a probe generates an error (that would have generated useful output 10 years ago). [/rant]

      >> Ignoring the first two

    This is a horrible assumption to make. I remember I looked at bringing Veracode in house specifically because I had a multi-million line legacy web app written in "classic ASP" that powered several hundred million dollars of annual purchases.

  • Meaningless conclusion. (Score:2, Insightful)

    by BVis ( 267028 )

    Observation: Most people are right-handed.
    Observation: Lots of people kill each other.
    Conclusion: Right-handedness makes you kill people.

    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.

    Now I'm not saying php hasn't had language-based security problems in the past (and currently), but anyone who still thinks it's as porous as it w

    • Re:Meaningless conclusion. (Score:5, Informative)

      by phantomfive ( 622387 ) on Friday December 04, 2015 @11:01AM (#51057087) Journal

      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)

      • Re: (Score:3)

        by jabuzz ( 182671 )

        But how many of these critical flaws are SQL injection flaws? As has been observed elsewhere every dam PHP howto seems to be keen on using dynamic SQL queries rather than using stored procedures that more or less kill SQL injection issues stone dead (that is unless you start using dynamic SQL in your stored procedure).

        What would be interesting is to see the SQL injection flaws removed from these figures.

        • But how many of these critical flaws are SQL injection flaws?

          If only there were an article you could read that had this information. Then you could read it and avoid making ignorant questions.

          As the article points out, code injection and XSS faults are much more common in PHP than SQL injection flaws.
          Of course, it doesn't mean that PHP is the worst language......for example, it could be that the worst programmers most often use PHP. More research is needed.

      • Interesting that Java and C++ have more flaws per MB than Android, given android apps are usually written in Java and sometimes with C++ mixed in. This implies more about the average Android coder vs the average Java coder than it does about the languages.

  • I assume they give the details on how this was done in their security report, which requires registering to download. From their wording they have a tool that scans for common security issues and report them. So where things ranks depends heavily on how accurate the tool is.

    Of interesting note is that java is higher than .NET and C++ on flaws, but lower on the list of critical flaws

    Javascript is at the bottom. My guess that is because you generally run javascript on the client, and good server architecture

    • Good questions, and I suggest downloading the report to confirm your answers. We won't bite.

      We report data in this study largely obtained from binary static analysis, run in Veracode's centralized environment where we can tune our engines for low false positive rates.

      JavaScript is at the bottom probably because at the time the data was pulled for this study (six quarters from Q4 2013 to Q1 2015), we only supported JavaScript in mobile application use. We have since added support for JavaScript in the web co

  • Classic ASP has more than 80% of the bugs. Why just ignore it? It ought to be a dead language, but it isn't. I happen to know that there is active programming happening in Classic ASP even now, despite the bugs.
    A finger is instead pointed squarely at PHP, which, with 25% of the applications represented on the internet, only represents less than 8% of the flaws. Not that I have any particular bias towards PHP, I don't even use it, but the finger needs to be pointed at where the trouble spots are, and Classic ASP tops the heap.
    Yesterday, I did a good deed. I taught a guy how to use ADO Commands and Command Parameters instead of inline SQL. He was running the inline SQL through some filters to try to catch certain SQL commands in an attempt to defeat SQL injection. So maybe the flaws/MB in Classic ASP will go down by some tiny iota.

    • We have quite a few classic ASP applications running. They were coded over a decade ago when that was what you used to develop web applications on IIS. I'd love to port these to PHP or some other language, but it's a time intensive process (both rewriting the code and testing it to find the bugs that the rewriting process introduced) and we don't have the manpower to rewrite EVERYTHING.

      Unfortunately, I've been directed that all new applications are to be written in Cold Fusion. So I'm moving from dead la

      • >> I'd love to port these (classic ASP apps) to PHP or some other language...all new applications are to be written in Cold Fusion

        Why not port to ASP.NET? I've done that conversion dozens of times now. And what kind of hell are you living in that Cold Fusion is even on table?

  • The problem is not the language, it is the coders (Score:5, Insightful)

    by gweihir ( 88907 ) on Friday December 04, 2015 @10:47AM (#51057001)

    You can write secure code in any almost any language (unless the run-time system is insecure, see for example the history of Java), and you can write insecure code in any language (yes, even in Rust, Swift and Go and other newfangled but not really better hype-languages). The difference is not the language. The difference are the people doing architecture, design and implementation. If some languages have more security problems, that is primarily because these languages attract less competent coders.

    Incidentally, absolute numbers are irrelevant. What we need is issues per application.

    • The difference is not the language. The difference are the people doing architecture, design and implementation. If some languages have more security problems, that is primarily because these languages attract less competent coders.

      Exactly this. Take classic ASP, for example. It's not the most recent language by any stretch of the imagination, but it's easy to check user input and escape it to prevent SQL injection attacks.

      SQLQuery = "Select UserID where Name = '" & Replace(UserEnteredName, "'", "''")

      • Re:The problem is not the language, it is the code (Score:5, Informative)

        by xxxJonBoyxxx ( 565205 ) on Friday December 04, 2015 @11:44AM (#51057463)

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

      • Why not go one step further, do "the right thing" and use ADO Prepared Statements? [owasp.org]

        • Thanks for that link. I'm not sure how I didn't know that classic ASP had prepared statements. Of course, my preferred method would be to convert the entire application off of classic ASP, but this might be a good stop gap method.

  • Managed languages (Score:4, Interesting)

    by johannesg ( 664142 ) on Friday December 04, 2015 @10:55AM (#51057043)

    So much, then, for managed languages. I thought managed pointers and garbage collection were supposed to free us from all those ills, but evidentally not.

    Shame that further down they perpetuate the myth of the C/C++ language. That language doesn't exist - it's either one or the other. In C you'd use raw memory pointers if you wanted to pass a buffer around, making it easy to access it beyond its boundaries. In C++ you'd pass a buffer object that knows its own size, and either dynamically resizes or at least throws an exception on an illegal access.

    Because C and C++ have such vastly different approach to the same problem I'd love to see C and C++ split out.

    • If you think the report has such bad things to day about Managed Languages it really depends on how you read it. Java ends up looking like it's just under PHP, but if you look at the Critical Flaws portion it's actually much better than C++. Heck, Javascript is the best overall, but it's easy to see why Javascript is so pervasive that it needs a fairly solid sandbox, or everyone's hit with the exploit. Which is why Java exploits are so bad it doesn't matter that Java has fewer critical exploits when the Jav
  • OK, so if I want to decrease my C++ vulnerability per MB of code metric, all I need to do is, depending on your definition of code, write a C++ program to produce large statically allocated arrays of garbage, or write a c++ program that... OH YES... FUNROLL LOOPS ON NOP INSTRUCTION..... I'm sure gcc will comply if I make that the only optimization, right?! Just increase the loop iterations to increase security! GENIUS!

  • ISO/IEC JTC1/SC22 has had a group looking at programming language vulnerabilities, including (a) how to define a 'vulnerability'; (b) how to assess languages against those definitions; (c) an assessment of languages (that have de-jure standards) for vulnerabilities, and related work. There is an introduction here http://www.open-std.org/jtc1/s... [open-std.org] and the work is documented here: http://grouper.ieee.org/groups... [ieee.org]

    (Do you suppose the authors of this report are aware of the ISO work?)

  • More complex than the headline. (Score:3)

    by Junta ( 36770 ) on Friday December 04, 2015 @11:15AM (#51057203)

    Some examples where things are more to do with the context than the language.

    For example, SQL injection very very high proportion of php code deals with a SQL database. However in other languages, this isn't quite as ubiquitous. The likelihood that a C++ application even touches SQL is far lower than a php application. Same for XSS (they referenced locally running iOS and Android applications, suggesting that not all code might even be dealing with scenarios where XSS is applicable).

    There are a few things where language choice is a factor (buffer overflow, buffer management), but there's a lot of attempts to compare very different applications to each other and assume equivalence.

    This is about problem domain where the language is popular more than it is about the language. It's an interesting commentary on the sorts of mistakes developers should be on the lookout for and perhaps motivation for language runtimes to think about things they might possible mitigate, but hard to say 'php is plain worse than objective c', which is what the report is saying.

  • We have more issues with the bugs our developers write than the ones inherited from the programming language.

  • I don't see any proof of causation, only correlation and even that is not well documented since there is no attempt to correlate programmers to bugs, or application type to bug or industry, etc, etc, etc.

    If MOST applications written by crappy programmers are done in a industry that normally attracts people that taught themselves to program yesterday and pays accordingly is there any surprise they might have a lot of security issues?

    Wordpress is designed to be used by people that have no idea how to spell se

  • I have helped develop a low budget site using coldfusion, as an unpaid volunteer. There is a lot of M$SQL too. I'm neither a security expert or a Coldfusion expert. There are other developers who are more experienced, but there has never been a security audit. I would be interested in the tool(s) used in the study, to scan our site for security issues. Are those tools or similar tools easily available (remember - low budget).

  • PHP is the worst (but not really) (Score:3)

    by corychristison ( 951993 ) on Friday December 04, 2015 @12:18PM (#51057727)

    I say this as a long time PHP developer. I've fiddled with other scripting languages (Python, NodeJS, Java/Tomcat), and I just find they are not very well suited for a web environment, so I always come right back to PHP.

    The problem is actually a few different things, not necessarily related to PHP itself:
    - Outdated installations are everywhere
    - Outdated and very poorly written Tutorials are even more prevalent
    - Lack of general understanding of security is a problem not relevant to any programming language

    Many of the security problems with PHP have been addressed long ago when the initial release of PHP 5 came out, and a few more since then.

    When interfacing with a Database, developers are now using PDO or a mechanism provided by their framework (usually built on top of PDO). This in and of itself has completely eliminated SQL injection attacks. The problems still cropping up are legacy applications that haven't been updated. Many of these can partially be attributed to outdated PHP installations.

    The majority of web hosts run cPanel. cPanel has been making big changes to their product. A few things they have done recently:
    - Dropped support for old PHP versions (oldest supported is now PHP 5.4)
    - Shifting to a binary package system (via yum repository) for PHP/Apache with safer default configs; previously it was up to the Admin to compile, install, and configure, also supports automatic updates
    - Included a mechanism in Apache to configure/utilize multiple PHP versions on a per-user, per-directory basis
    - Included support for Apache MPM-ITK [sesse.net]; allows each virtualhost to be run as a specific UID:GID instead of all sites running under the same UID, greatly increasing per-account security so long as each accounts file permissions are secure.

Slashdot Top Deals

Technology is dominated by those who manage what they do not understand.

Close