[dlor]

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

[waihtis]

The gap from knowing what a CWE is and actually knowing, on code level, how it manifests and how you avoid these things is very large. Given how much the software industry has grown in the past 10 years it's not particularly surprising.

[p-e-w]

> and actually knowing, on code level, how it manifests and how you avoid these things

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

[paulmd]

XSS is a great example of that. On paper a ton of people know exactly what XSS is and does. In practice... simply don't allow user-controlled input to be emitted unescaped, ever. Good luck!

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?

[tialaramex]

Two of those four are things there's no need to make easy to do by mistake, but two popular programming languages choose to do so anyway and they reap the consequences.

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.

[mattgreenrocks]

Our industry is ageist and anti-intellectual. These are the symptoms of those.

[p-e-w]

While I agree that the software industry suffers from ageism and anti-intellectualism, these vulnerabilities are actually the symptoms of elitism, cargo culting, and traditionalism, which it also suffers from.

[lusus_naturae]

Maybe not ageist, but I do think it's easier to get younger people to work slavishly and pay them relatively less (on average, not everywhere pays like Bay area).

[poiuyt098]

Could be worded as Low barrier to entry and highly compensated.

Kids get into it just by having the tenacity to do whatever it takes to make it chooch. It's all that counts.

[geodel]

Ageist against old people? young people? middle-age people? I see at least these 3 categories are facing age related issues.

[tumdum_]

"But modern c++ is safe, preventing all those errors is as easy as not making them!..."

[citrin_ru]

Is there some authoritative source for what is considered modern C++ and what is old? Most projects I've seen use a wide mix of C++ features of varying age. If you use some C++23 futures it would not make it modern if you still use C++98 features you not supposed to use.

[littlestymaar]

In fairness, only 2 of those 4 are actually memory-related.

[throwawaaarrgh]

It's somewhat disheartening as a security enthusiast that people only focus on "popular" security bugs and ignore the rest. The other top 21 bug classes aren't as "cool" but they will let me hack your app just the same.

[HideousKojima]

Sure, but SQL Injection will let a script kiddie steal and/or drop your entire poorly configured production DB.

[Mountain_Skies]

SQL Injection is weird because it's been known for so long and modern frameworks usually have so many ways of avoiding it by default, that's one has to go out of their way to create an injection vulnerability, but it still happens often with greenfield code.

[anonzzzies]

> mproper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

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

[valenterry]

Then ask yourself: how much have you done to prevent people choosing the wrong programming language? Because the PL has such a major influence, it's by far the most low hanging fruit to tackle those many of those issues.

[dlor]

Personally? I've done quite a bit here although there's always more. I worked at Google to fund Rust development internally and externally, helped sponsor the work that eventually led to getting Rust adopted in the Linux kernel, and now run a company that's building a new Linux distribution that prioritizes shipping code written in memory safe languages.

https://security.googleblog.com/2021/02/mitigating-memory-sa...

https://www.chainguard.dev/unchained/building-the-first-memo...

[akmittal]

How many of these rust can solve?

(Not in use rust for everything bandwagon, genuinely curious)

[dlor]

SQL injection and XSS are typically solved at a library/framework level instead of a programming language one, although type systems can help make those frameworks usable and work well.

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.

[dgb23]

Judging from my limited experience the first and fourth are either caught by the compiler or at least result in a panic in some cases.

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.

[speedgoose]

2 of the 4 listed.

[ok123456]

Items 4 and 12 and only in obvious cases.

[synergy20]

for 1 scan all the code base and warn any use of strcpy/strncpy/etc and replace them with snprintf, no APIs without length argument shall be allowed.

for 4 the static analyzer should help, and, also set your pointer to NULL immediately after free too(for double free)

[UncleMeat]

Static detection of UAF is grossly incapable of actually protecting real C++ applications. It can find some bugs, sure. But a sound analysis is going to just throw red all over a codebase and get people to disable it immediately.

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.

[actualwitch]

> top four elements are still

Use after free is actually gaining popularity, up 3 since last year.