* 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
Actually the SQL one is arguably in that category too, to a lesser extent. Libraries could, and should, make it obvious how to do parametrized SQL queries in your language. I would guess that for every extra minute of their day a programmer in your language must spend to get the parametrized version to work over just lazy string mangling, you're significantly adding to the resulting vulnerability count because some of them won't bother.
Bonus points if your example code, which people will copy-paste, just uses a fixed query string because it was only an example and surely they'll change that.
I know it's the nuclear option, but decades of experience has shown that the wider industry just cannot be trusted. People won't ever change[1], so the tools must change to account for that.
[1] Unfortunately, LLMs learned from people... so... sigh.
You avoid them by using tools that make it difficult or impossible to introduce such vulnerabilities to begin with. Such as modern, memory safe programming languages.
For many decades, carpenters have been educated about table saw safety. But what finally stopped thousands of fingers getting chopped off every year was the introduction of the SawStop, and similar technologies.
Safety is a matter of using the right tools, not of "taking better care".
Afaik the technology isn’t widespread and there are still 10s of thousands of injuries per year.
"Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own."
-- https://www.bell-labs.com/usr/dmr/www/chist.html
Then source tapes with an almost symbolic license price for its time, and a commentary book did the rest.
Then there is the whole issue of making it more interesting to look elsewhere instead.
When a door is locked I can still break in by throwing a rock to the window, yet most people do lock the door nonetheless, while most thieves only bother to break the window if there is anything actually valuable in doing so.
I will take this bet.
No. All tools can be used with an improper attitude which leads to the creation of weak points.
The proper way is to have a deep understanding of the role of design rules.
A programmer who does not pay attention to design (very basic principles of the design process) can create a good game, and even if this game contains weaknesses the risk related isn't a reason to not use it. The same programmer when creating critical infrastructure software is a source of potential nightmare.
Unfortunately, software business accepts such specialists for projects both of kinds. Why? Who knows? Perhaps because of legal regulations? Why when an engineer designs a car they don't try to "Move fast and break things"?
They do when they design submersible or rockets
Similarly, I imagine that there are cases where someone needs to do complex wood working tasks that involve dangers which are a less obvious than with a table saw.
The reason XSS (and CORS) are tricky is because they fundamentally don't work in a world where a website may be spread over a couple different domains. I get a taste of this in my dayjob where we have to manage cookie scoping across a couple different region domains and have several different subdomains for different cookie behaviors. It's easy to be clean on paper up until you need to interface with some piece of software that insists on doing it its own way - for example the Azure excel embedded functionality requires the ID token to be passed in the request body, meaning you have to pull in the request body and parse it in your gateway layer (or delegate that to a microservice)... potentially with multi-GB files being sent in the body as well!
It's super easy on paper to start from greenfield and design something that is sane and clean, bing boom so simple. But once you acquire a couple of these fixed requirements, the cleanliness of the system degrades quite a bit, because that domain uses a format that's not shared by anything else in the system, and it's a bad one, and we can't do anything about it, and now that's a whole separate identity token that has to be managed in parallel.
Anyway, you could say that buffer overflow or use-after-free are kind of an impedence mismatch for memory management/ownership in C. Well, XSS and CORS are an impedence mismatch for domain-based scoping models in a REST-based world. Obviously the correct answer is to simply not write vulnerable systems, but is domain-based scoping making that easier or harder?
Kids get into it just by having the tenacity to do whatever it takes to make it chooch. It's all that counts.
An argument for more often: C++ is so complicated, maybe you're too busy with other problems to address the neutralization issue
An argument for less often: C++ teaches you to be careful and check everything to avoid nasty outcomes so that carries over to neutralization
Coverity exists. They've got a great product. But it doesn't solve the problem.
I love static analysis. I did my PhD in it. But we'll still be talking about use after free in 2073 if we just try to chase higher K in our analysis implementations.
The main issue is the community sub-culture of not adopting tooling as it isn't perfect 100% of the time.
Many of the C++ security conscious folks end up being polyglot, as this subculture eventually wears one out.
Again, even if not perfect, and doesn't cover all use cases, what about people would actually use something at all?
During that decade, how much time did you spent looking at the human side of the problem instead of what the tools can achive?
My only point is that without a different approach we will continue to have the same problems in 2073.
It's somewhat similar to the C/C++ split. When it is convenient it's "C/C++" because "you can easily migrate your old C codebase to C++". But in other situations it's "C++", because C is old and more error prone and "we no longer manipulate raw pointers".
Started with the publishing of "Modern C++ Design" from Andrei Alexandrescu in 2001.
https://en.wikipedia.org/wiki/Modern_C%2B%2B_Design
When ISO C++11 came to be, many re-used the term to mean C++11 or higher.
Given that many keep updating this to mean more modern versions, a well known developer in the community (Tony Van Eerd) has made the joke of that by C++17 time we were in Postmodern C++.
https://www.youtube.com/watch?v=QTLn3goa3A8
No idea what kind of modernism to call C++23, when C++17 was already postmodern, maybe Revivalist C++.
However it basically comes back to Andrei Alexandrescu's original ideas of programming in C++ as its own language, leave the C ways and pitfalls of resource management behind, learn to embrace a modern language for systems programming.
I should also note that there are developers against this philosophy, they advocate that the C++ as understood by CFront is what one should care about, thus Orthodox C++ movement was born.
I'm with Kate Gregory on the "Stop teaching C" (actually Kate specifically means in order to then teach C++ but I also think it's probably fine to stop teaching C outright)
But whilst Kate is right in terms of pedagogy, as a larger philosophy this is inadequate. As a language C++ is obviously defective and the explanation is almost invariably "Because C" which only makes sense once you appreciate C++ in terms of C.
The built-in array type in C++ is garbage. Why is it garbage? This is a language with all these powerful features, why doesn't its array type leverage any of them? It's because this is actually the array type from C.
OK, maybe just the array type is trash, that's obviously not good, but it's one defect. How about string literals. Oops. C++ does sort of technically have the string literals you actually wanted, but the syntax for them is weird and you need the standard library not the core language... the ones you get for "Some text" are C's constant strings, an array of bytes with an extra zero byte, and well, the array type sucks.
This carries on, the language doesn't provide real tuples, it doesn't provide a real sum type, its built-in types don't believe in methods but user types do, everywhere there are weird choices which are non-sensical except for the reality that it's what C does.
And then at the end of that, the language isn't actually compatible with C. It's close, a lot of stuff works, and more stuff kinda-sorta works enough that you may be surprised when it fails, but there isn't the sort of robust compatibility you might expect given the enormous sacrifices made for this goal.
The issue is how "worse is better" culture tends to win, and if the option is between C and C++ for a given scenario, then I definitely take C++.
However if the option pool is widened to more alternatives, then yeah, there should be a sound reason for still pick them for greenfield development, e.g. CUDA, a language toolchain based on LLVM,...
This is often ignored as it simply takes too much time and it often does not hurt much as it’s ‘internal’ (to the company using the saas or whatever).
https://security.googleblog.com/2021/02/mitigating-memory-sa...
https://www.chainguard.dev/unchained/building-the-first-memo...
(Not in use rust for everything bandwagon, genuinely curious)
The middle two are out of reach of a typical PL or type system (there are exceptions like Ur, but I don't think it's adopted widely). It's a problem that is typically solved via libraries and Rust is not unique in terms of providing safe libraries around generating SQL or HTML.
However, existing libraries for statically-typed languages often don't do the work or apply the creativity and end up roughly as unsafe as the dynamically typed languages.
It's a bit of a pet peeve of mine.
Either way, they're effectively "solved" from a programmer's perspective if you're willing to adopt modern frameworks instead of string-concatenating HTML or SQL manually.
for 4 the static analyzer should help, and, also set your pointer to NULL immediately after free too(for double free)
Changing everything to take lengths is definitely a good change - but challenging to retrofit into existing codebases. Apple has a neat idea for automatically passing lengths along via compilation changes rather than source changes, but if you want to do things in source you have to deal with the fact that there is some function somewhere that takes a void*, increments it locally, reinterpret_casts it to some type, and then accesses one of its fields and you've got a fucking mess of a refactor on your hands.
Use after free is actually gaining popularity, up 3 since last year.