7 ms·

Here are Language-Specific ones: 1. CWE-787 Out-of-bounds Write: C, C++, Assembly 4. CWE-416 Use After Free: C, C++ 7. CWE-125 Out-of-bounds Read: C, C++ 10

• dgb23 3y ago
  PHP is uniquely vulnerable to things like XSS and others on that list, because it does escape strings that are used in templating. Escaping by default has become a standard practice with HTML templating languages, see the Go html template standard library for a very detailed breakdown of what is escaped where. More modern PHP frameworks like Laravel provide their own templating solution in part because of this. But the vast majority of websites run on default PHP templates, so it's not surprising that these kinds of vulnerabilities are so high up in the list.
  • jacquesm 3y ago
    Laravel has had their own share of XSS issues with their Blade templating engine. The whole problem is that you mix code and data, and that third party resource loading is 'on' by default in browsers, especially for scripts and things that can embed scripts. This is not something you can fix once and for all at the library level.
• Xeamek 3y ago
  >12. Null pointer deref. In java you'll get an exception, while in C you might dissapear your cat. Those 2 are quite incomparable when talking about "dangerous-ness" of a mistake
  • jiggawatts 3y ago
    And C# is making references non-nullable by default.
    • pjmlp 3y ago
      Kind of, it doesn't work that well with existing libraries, and because of that, even when you enable it, it is only a warning.
• throwawaaarrgh 3y ago
  People have language blinders on. It's not like if you only focus on the ones that affect your language specifically, suddenly you're secure. There's still another 16 bug classes to worry about. If you don't think about the other classes, I'm still gonna escalate privileges, root your box, ransom your data, send spam, charge a half million dollars in cloud spend to your account, steal your customers' PII/PHI, etc etc etc. Without ever using a language specific exploit.
  • vacuity 3y ago
    Yes, but such neglect of other bug classes suggests that those developers aren't focusing on security anyways. For those who do want reasonable security, using a memory-safe language suddenly makes the most pervasive errors go away, and then it's easier to focus on building robust applications.
• mojosam 3y ago
  Isn’t #17 the same as #1 and #7 combined?
• loup-vaillant 3y ago
  So, the memory related ones are in position 1, 4, 7, 12, 17, and 21. I understand memory safety is important, but still: only one in the podium (though it is first), only 3 in the top 10… clearly security is about much more than memory safety.
  • UncleMeat 3y ago
    Of course. Security is the exercise of making programs not do things. Since the very beginning of computer science we've understand that programs want to be able to do anything at a very fundamental level. We'll never solve security completely. But it is embarrassing that we've been living with memory safety issues for 50 years and they still remain very common and very severe, despite being addressable via type systems in ways that something like a logical bug that leads to data leakage isn't.
  • jerf 3y ago
    This isn't about choosing security measures from a menu. This is about the foundations of what you build. To the extent that memory safety is slowly, oh so slowly, but steadily dropping down the list, it is because we are taking it seriously as a foundational issue and actually addressing it. To turn around and then use the success we've had as evidence that it isn't important is making a serious error. There is no reason to use a memory unsafe language anymore, except legacy codebases, and that is also slowly but surely diminishing. I'm still yet to hear this amazingly compelling reason that you just need memory unsafe languages. In terms of cost/benefits analysis, memory unsafety is literally all costs. Even if you do have one of the rare cases when you need it, and you only need a very particular variant of it (reading bytes in memory of one type as bytes of another type, you never need to write out of the scope of an array or dereference into an unallocated memory page), you can still get it through explicit unsafe support that every language has one way or another. You do not need a language that is pervasively unsafe with every line you write so that on those three lines of code out of millions that you actually need it, you can have it with slightly less ceremony. That's just a mind-blowingly bad tradeoff and engineering decision. How are we supposed to address the other issues from a foundation of a memory unsafe language? If we can't even have such a basic guarantee, we sure aren't going to get more complicated ones later.
• runeks 3y ago
  > 15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript > 21. CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'): C, C++, Java Why those languages specifically? I would say these two issues apply to all languages.