Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CWE Top Most Dangerous Software Weaknesses

cwe.mitre.org

Post reply on HN
Print view View original

31–40 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#31

Post by throwawaaarrgh »

pulse7 wrote: post #14

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…

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.

Re: CWE Top Most Dangerous Software Weaknesses

#32

Post by p-e-w »

waihtis wrote: post #12
dlor wrote: post #2

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

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.

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

Re: CWE Top Most Dangerous Software Weaknesses

#33

Post by valenterry »

dlor wrote: post #2

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

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.

Re: CWE Top Most Dangerous Software Weaknesses

#34

Post by gemanor »

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.

Re: CWE Top Most Dangerous Software Weaknesses

#35

Post by Mountain_Skies »

dlor wrote: post #2

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

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.

Re: CWE Top Most Dangerous Software Weaknesses

#36

Post by wffurr »

p-e-w wrote: post #32
waihtis wrote: post #12

Earlier quoted context omitted.

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.

> 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 introduct…

C is the table saw of programming. C++ is the band saw.

Re: CWE Top Most Dangerous Software Weaknesses

#37

Post by dlor »

valenterry wrote: post #33
dlor wrote: post #2

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

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.

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

Re: CWE Top Most Dangerous Software Weaknesses

#38

Post by ok123456 »

akmittal wrote: post #13
dlor wrote: post #2

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

How many of these rust can solve? (Not in use rust for everything bandwagon, genuinely curious)

Items 4 and 12 and only in obvious cases.

Re: CWE Top Most Dangerous Software Weaknesses

#39

Post by davemp »

p-e-w wrote: post #32
waihtis wrote: post #12

Earlier quoted context omitted.

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.

> 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 introduct…

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

Afaik the technology isn’t widespread and there are still 10s of thousands of injuries per year.

Re: CWE Top Most Dangerous Software Weaknesses

#40

Post by amelius »

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.

Post reply on HN