Aside from Memory Management, there's another general category that always comes up in these lists, but is not talked about much: in-band signaling (i.e., "Strings are Evil"):
- Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (#2)
- Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (#3)
- Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') (#4)
- Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (#8)
- Improper Neutralization of Special Elements used in a Command ('Command Injection') (#16)
- Improper Control of Generation of Code ('Code Injection') (#23)
All of these came from trying to avoid structured data, and instead using strings with "special characters". It's crazy how many times this mistake has been repeated: file paths, URLs, log files, CSV, HTML, HTTP (cookies, headers, query strings), domain names, SQL, shell commands, shell pipelines... One unescaped character, from anywhere in the stack, and it all blows up.
One could say "at least it's human-readable", but that's not reliable either. Take files names, for example. Two visually identical file names may map to different files (because confusables[1] or surrounding spaces), or two different names map to the same file (because normalization[2]), or the ".jpg" at the end may not actually be the extension (because right-to-left override[3]).
So the computer interpretation of a string might be wrong because a special character sneaked in. And even if everyone was perfectly careful, the human interpretation might still be wrong. For the sake of the next generations, I hope we leave strings for human text and nothing more.
[1] https://unicode.org/cldr/utility/confusables.jsp
[2] https://developer.apple.com/library/archive/qa/qa1173/_index...
[3] https://krebsonsecurity.com/2011/09/right-to-left-override-a...
Mitre really lost a lot of respect with CVE-2016-1000027. Every few weeks a warning that any SpringBoot 2.x project has a CVSS 9.8, which causes all sorts of heartache for those of us bound to CVE remediation. Every blasted security tool reports this one. Spring reviewed and rejected, as did our very, very large organization. Comically, this has become the CVE we use to see how our tools allow us to white/black list entries.
Thank god Spring dropped this interface in the Framework 6.x / Boot 3.x release, and the end for non-commercial support is this year for the old stuff.
https://github.com/spring-projects/spring-framework/issues/2... https://github.com/advisories/GHSA-4wrc-f8pq-fpqp
It should be considered a failure of our profession that after all these years the number 1 issue is still out of bounds write, a memory safety issue. In any true engineering profession a failure of this sort would be unacceptable, but in ours it's tolerated and explained away as a necessary byproduct of certain tools. How much personal information has been compromised due to these low standards? How many people put at risk? It's shameful.
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. CWE-434 Unrestricted Upload of File with Dangerous Type: ASP.NET, PHP, Class: Not Language-Specific
12. CWE-476 NULL Pointer Dereference: C, C++, Java, C#, Go
15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript
17. CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer: C, C++, Assembly
21. CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'): C, C++, Java
23. CWE-94 Improper Control of Generation of Code ('Code Injection'): Interpreted
Is anyone using Valgrind even anymore these days?
I've noticed that using Valgrind on Python systems is almost impossible because most modules have not been built with Valgrind in mind and thus you get swamped in noise.
I suppose the same is true for any large system that uses many different third party libraries.
I'm really waiting to see all those shift-left startup founders that will craft a new world of developer-oriented products from this list. IMHO, the real way to look at it is how we can influence developers (by choosing the suitable languages, platforms, architectures, etc.) and then measure them after they find the vulns.
From the optimistic side, it looks like the safest language to write an app today with is TypeScript.
Wordle sold for a $1M+ and put all the solutions for the future games into the javascript file. Security is important, but its a spectrum.
CSRF higher than improper auth? Yeah...don't think so.
It's somewhat disheartening as a software developer focused on security that the top four elements are still:
* Out-of-bounds Write
* Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
* Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
* Use After Free