Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Soulskill on 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.

43 of 241 comments (clear)

  1. normalized? by Anonymous Coward · · Score: 5, Insightful

    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.

  2. Self-fulfilling prophecy? by mindmaster064 · · Score: 3, Insightful

    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!

    1. Re:Self-fulfilling prophecy? by paulpach · · Score: 4, Insightful

      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.

      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.

    2. Re:Self-fulfilling prophecy? by hey! · · Score: 3

      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.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  3. Apps, it had to be apps by Anonymous Coward · · Score: 2, Insightful

    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 "extinct" according to whoever wrote the summary) they are the top 3 languages for quickly kludging new functionality into fairly simple web pages.

    1. Re:Apps, it had to be apps by Archangel+Michael · · Score: 2

      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.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    2. Re:Apps, it had to be apps by bigman2003 · · Score: 2

      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? People love the apps. They also love the fact that I can create them so quickly. And they love the fact that whenever they ask for something new I say, "Sure, I can do whatever you need." That's what 17 years of experience gives you- I can churn out high quality code very quickly. I still need to defend CF every time I say, "I'm a programmer" because they always want to know what language I use. Because their nephew is learning Swift and that's cool...etc. etc.

      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. I have CF code that I wrote 16 years ago that is still running, and still serving up millions of pages per month. My new code is pretty damn rock-solid, and I know how to write things in a way that is very easily maintained and updated. Because I've been doing it for a long time...

      PHP is now in the same spot as ColdFusion, in the sense that it's no longer the cool thing to do, but there is a crapload of experience out there. In my opinion a good experienced programmer is worth 8 'language of the day' programmers no matter what language they are using.

      I've been on my latest project for about 18 months. It will take another 6 months before I'm 'done' to the point where I've completed all of the initial goals - this was the assumed timeline at the beginning...again, I've done this for a while, I can estimate a timeline pretty well. The project is being used every day and has already replaced the older system but there are few more milestones to hit.

      But the most important part of the project is that everything is clean. The database has been re-worked extensively as I've had more and more experience with how the data is used. When this project is re-written in the future, it will be much easier because the data will make sense. The last programmers just threw more technologies at the project to solve problems, rather than fixing what was broken. (A nice Javascript data interface can't really replace clean data...no matter how much pagination and filtering your fancy table has) I see that a lot with younger programmers. By far this is the most important part of the project and is not language specific. "Does this entire thing make sense? Have you done the tough work instead of a million work arounds?" That to me is far more important than working on a language that has yet to see version 3. (No magic to version 3, just looking at the maturity of the language)

      I wish more people in the industry were concerned about quality, rather than the new and shiny. Not a single user has said, "Oh this sucks because it is written in ColdFusion". Instead they say, "Oh my god, this is exactly what we wanted...and you are so fast!"

      I am so tired of people doing one or two projects in a language, then moving on to the next new and shiny- while bashing on CF because it's old. Goddamit, I'll be cleaning your messes up in the future and there is a good chance the pages will have a .cfm extension even if it's not cool.

      It's like thinking you are a good photographer because you've got the latest camera. Superficially it's nice, but you still have no idea what you're doing.

      --
      No reason to lie.
    3. Re:Apps, it had to be apps by mikael · · Score: 2

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

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  4. Whew! by scunc · · Score: 2

    Good thing I'm still using Perl!

  5. And that's surprising ... how? by Opportunist · · Score: 4, Insightful

    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.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  6. What's a "programming language"? by david.emery · · Score: 3, Interesting

    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?

    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:What's a "programming language"? by aaaaaaargh! · · Score: 2

      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!

    4. Re:What's a "programming language"? by david.emery · · Score: 2

      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 much real experience in Ada (I kinda doubt it.)

      There are some things that are very concise in C or C++. There are also some things that are very concise in Ada (imagine how many hundreds of lines of C and threads packages you need to code to get the equivalent of Ada tasking rendezvous.)

      True story: as part of an experiment we implemented part of TCP (in particular, the timeout provisions associated with NAK) in both Ada95 and C. It took me 5 lines of Ada95 (Asynchronous Transfer of Control) to do what the other developer (who had experience coding protocols) did in 300 lines of C. His code had a bug in it, too.

    5. Re:What's a "programming language"? by phantomfive · · Score: 2

      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++?

      --
      "First they came for the slanderers and i said nothing."
  7. Reason for this by xxxJonBoyxxx · · Score: 3, Interesting

    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.

  8. Meaningless conclusion. by BVis · · Score: 2, Insightful

    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 was when version 4 was current needs to do their homework. Nowadays most of the issues come from stupid code, not the language itself. php's low barrier to entry attracts people who don't know how to write a more-secure web app in disproportionate numbers. See this for how to do it right.

    --
    Never underestimate the power of stupid people in large groups.
    1. 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."
    2. Re:Meaningless conclusion. by jabuzz · · Score: 2

      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.

    3. Re:Meaningless conclusion. by BVis · · Score: 2

      Or, I'm sick of people bashing php for things that aren't structural/language issues.

      --
      Never underestimate the power of stupid people in large groups.
  9. Why ignore the ones that had more than 80% of bugs by tompaulco · · Score: 2

    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.

    --
    If you are not allowed to question your government then the government has answered your question.
  10. The problem is not the language, it is the coders by gweihir · · Score: 4, Insightful

    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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  11. Re:PHP is Fine by TWX · · Score: 4, Insightful

    The problem is the users, PHP is so ridiculously easy to write it leads to people making horrible insecure "awesome" webpages.

    I'll let you in on a little secret, the problem is always the users, regardless of technology. That's why some disciplines have separate security tracks from their development or administration tracks, because the concepts run completely contrary to each other. Development is there to provide access. Security is there to prevent access. At some point the two need to come to a compromise, but trying to get developers to do security is about as useful as trying to get security professionals to do development.

    --
    Do not look into laser with remaining eye.
  12. Re:Are all ten of them Java? by tompaulco · · Score: 5, Interesting

    Just wondering.

    Java is the 4th highest, with about 2% of the flaws found being Java. I'm really shocked that Java shows up higher on the list than Javascript. If ever there was a language where people copy and paste somebodiy's working code and try to mangle it to work for their own purposes with no understanding of the actual language or security thereof, it is Javascript.

    --
    If you are not allowed to question your government then the government has answered your question.
  13. Managed languages by johannesg · · Score: 3, Interesting

    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.

  14. Re:Wondering how they measure this by tjarrett · · Score: 2

    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 context, specifically with support for JQuery and Node.js, and expect the picture for JavaScript vulnerabilities to change when we do the next report. That's one reason we didn't include JavaScript in our high level conclusions for the report..

  15. Re:Are all ten of them Java? by Anonymous Coward · · Score: 2, Interesting

    The days of copying and pasting JavaScript and hoping that it works are long gone (perhaps 10 years).

  16. Bug for bug compat w/o conspicuous deprecation by tepples · · Score: 2

    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 such in the manual, such as by changing the background styling, is a bug. Failure to log use of deprecated functions by default is a bug. Requiring the server operator to silence deprecation warnings server-wide just to run a particular legacy app is a bug. This means the server administrator or shared hosting customer needs the ability to suppress logging of particular deprecated functions used by particular legacy apps while continuing to log other deprecated functions and the same functions used in other apps.

  17. More complex than the headline. by Junta · · Score: 2

    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.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  18. Re:Are all ten of them Java? by Z00L00K · · Score: 3, Interesting

    The report only concerns security bugs, not all bugs. Most security issues with JavaScript are likely to have been hammered out now.

    But JavaScript do fail from time to time on web pages, especially if there's a web page that do something that was permitted in an earlier version but not permitted any longer due to a security issue with that functionality. Another headache with JavaScript that most programmers today have rectified is browser differences.

    Some browsers have taken in functionality from competing browsers to ensure compatibility so some issues with JavaScript have been resolved that way as well.

    Java libraries - they are good, but also a curse since you can't ensure that you get everything right with the library functions in all cases. Experienced programmers may have their own library of JavaScript functions to use when they make their web stuff.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  19. Re:Are all ten of them Java? by DrXym · · Score: 2
    I expect that languages that allow (nay encourage) embedding SQL straight into the web template are the ones most vulnerable to attack.

    Java web apps would typically split the presentation, logic and storage from each other and the storage would be via Hibernate / OpenJPA. These impls would tend to be robust and prevent most forms of injection attack.

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

  21. OK, so what do I do now by lightperson · · Score: 2

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

  22. Re:Languages make bugs easier by gweihir · · Score: 2

    These bugs are mostly irrelevant. The ones that matter is where the programmer did not understand the code he/she wrote. And that is a problem before the keyboard.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  23. Re:Are all ten of them Java? by jimbolauski · · Score: 2

    1)Exploit google's algorithm to make my functions for print, find, sort,... top on search listings
    2)Direct users to my website supported by page view adds
    3)Profit

    --
    Knowledge = Power
    P= W/t
    t=Money
    Money = Work/Knowledge so the less you know the more you make
  24. Re:Are all ten of them Java? by neurojab · · Score: 2, Interesting

    >If ever there was a language where people copy and paste somebodiy's working code and try to mangle it to work for their own purposes with no understanding of the actual language or security thereof, it is Javascript.

    In the majority of web applications the client is given limited scope by the server. Clients can't be given full trust because anyone can create their own malicious client. Security bugs are therefore on the server. Today most javascript is still client side. Yes, node.js has been making inroads, but it is far from the most popular server side language. I predict that if node does eclipse java in popularity, it will also beat java in server side security bugs. Perhaps by a wide margin, since I've also seen a lot of client side programmers work on server code in node. If you're used to being on the untrusted side of things and then suddenly have to make secure code, you're bound to make mistakes.

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

  26. PHP is the worst (but not really) by corychristison · · Score: 2

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

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

  28. Re:Full Stack (Overflow) Developers by njnnja · · Score: 2

    Nice link. But how can one deny the beauty of this new language?

    Example: Hello world
    stack overflow java hello world

    Example: Print Fibonacci numbers
    python generate fibonacci numbers
    python how to print a list

    Example: Normalize a vector to length 1
    c++ callback function fill array with values
    c++ array out of bounds error
    c++ how to install boost
    c++ smart pointer initialize array with zeros
    c++ normalize multidimensional vector
    c++ how to install gsl
    c++ convert array to gsl vector
    c++ how to end function and return value
    c++ how to compile to a shared library

  29. Re:Are all ten of them Java? by edsousa · · Score: 2

    Humm, what?

    K = W / M Multiplying both sides by M
    K M = W M / M

    Simplifying
    K M = W

    Dividing by K
    K M / K = W/K

    Simplifying
    M = W/K

  30. Re:Are all ten of them Java? by GodelEscherBlecch · · Score: 2

    Let's not forget also that the tooling involved in these surveys is not magic. I have monthly SCA audits and at least 60% of the 'critical' issues it finds are pure nonsense. Things like indirection, polymorphism, chains of data custody, what is/not a public API are not well understood by the scan engine. If I make 10 classes that pass/access a variable, and only the first one has a public API and is ever called by anything other than the one before it, the SCA will tell me that I have 9 classes that are not doing proper null / boundary value / SQL injection / etc. checking.

    The time that I have spent fixing actual potential issues found by SCA is dwarfed by the amount of time I have spent learning its heuristics just so that I can write the code in a way that obfuscates the 'issue' so I can skip the argument with our security 'experts'.