Live data from Hacker News

CWE Top Most Dangerous Software Weaknesses

cwe.mitre.org

11–20 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#11
post #3

Earlier quoted context omitted.

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

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.

not authoritative, but the really big c++ change was with c++11 - changes after that have been important, but perhaps more or less transparent to the average c++ user. and compiler support for c++11 is very good.

Re: CWE Top Most Dangerous Software Weaknesses

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

Re: CWE Top Most Dangerous Software Weaknesses

#13
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)

Re: CWE Top Most Dangerous Software Weaknesses

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

Re: CWE Top Most Dangerous Software Weaknesses

#15
post #3

Earlier quoted context omitted.

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

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.

“Modern C++” is not necessarily tied to any specific standard, it is more a collection of ideas and philosophies. Although if I had to pick I’d say it really started with C++11.

Re: CWE Top Most Dangerous Software Weaknesses

#16
post #3

Earlier quoted context omitted.

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

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

I agree that in principle the neutralization bugs aren't something C++ is necessarily making worse than, say, Python. But it'd be fascinating to see a study to figure out whether C++ programmers make these mistakes more often, or less often, or roughly the same.

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

Re: CWE Top Most Dangerous Software Weaknesses

#17
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)

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.

Re: CWE Top Most Dangerous Software Weaknesses

#18
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)

2 of the 4 listed.

Re: CWE Top Most Dangerous Software Weaknesses

#19
post #3

Earlier quoted context omitted.

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

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

In fairness, only C/C++ of all the currently commonly used languages can have half of the 4 top dangerous software weaknesses.

Re: CWE Top Most Dangerous Software Weaknesses

#20
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)

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.

Post reply on HN