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

61–70 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#61

Post by HideousKojima »

throwawaaarrgh wrote: post #30
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

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.

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

Re: CWE Top Most Dangerous Software Weaknesses

#62

Post by runeks »

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…

> 15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript

> 21. CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'): C, C++, Java

Why those languages specifically? I would say these two issues apply to all languages.

Re: CWE Top Most Dangerous Software Weaknesses

#63

Post by BoppreH »

Therenas wrote: post #57
BoppreH wrote: post #48

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…

What‘s the alternative though? For URLs for example, would you have to put a JSON structure into the browser? That‘s obviously not going to happen.

Sure, most of these decisions are too entrenched to be fixed.

But yes, URLs should have been structured. We already see paths rendered with breadcrumbs, the protocol replaced with an icon, `www` auto-inserted and hidden, and the domain highlighted. If that's not a structure, I don't know what is.

By cramming everything into the same string, we open ourselves to phishing attacks by domains like `www.google.com.evil.com`, malicious traversal, 404s from mangled relative paths, and much more.

Re: CWE Top Most Dangerous Software Weaknesses

#64

Post by matt2000 »

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.

Re: CWE Top Most Dangerous Software Weaknesses

#65

Post by pixl97 »

BoppreH wrote: post #48

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…

Humans think in strings so it's not surprising we carry this thinking to code where it blows up in our face.

Re: CWE Top Most Dangerous Software Weaknesses

#66

Post by ludovicianul »

BoppreH wrote: post #48

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…

And it's even worse when everything is a map, rather than specific object schemas.

Re: CWE Top Most Dangerous Software Weaknesses

#67

Post by userbinator »

BoppreH wrote: post #48

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…

No, IMHO escaping is an elegantly simple concept; it's just that for some reason (like basic arithmetic) people don't seem to be taught enough about it to understand.

Two visually identical file names may map to different files (because confusables[1]), 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]),

Those are all because of Unicode, which is an even worse idea in general.

Re: CWE Top Most Dangerous Software Weaknesses

#68

Post by UncleMeat »

chefandy wrote: post #42
p-e-w wrote: post #32

Earlier quoted context omitted.

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

Those two things aren't mutually exclusive. I'll bet a non-trivial number of XSS and SQL injection vulnerabilities came from people disabling input and output sanitation on solid frameworks and libraries because they didn't know why they shouldn't. Tools won't solve all of your problems-- you need knowledge, diligence, and tools that make doing the right thing easy.

> I'll bet a non-trivial number of XSS and SQL injection vulnerabilities came from people disabling input and output sanitation on solid frameworks and libraries because they didn't know why they shouldn't.

I will take this bet.

Re: CWE Top Most Dangerous Software Weaknesses

#69

Post by UncleMeat »

pjmlp wrote: post #55
deadletters wrote: post #52

Earlier quoted context omitted.

And both have existing tools to find those bugs that people often just don't use.

Since 1979 with the invention of lint by Stephen Johnson at Bell Labs. https://en.wikipedia.org/wiki/Lint_(software)

Static analysis as a bugfinding tool has proven to be insufficient, especially for large C++ binaries and JS programs. Both languages are nightmares for precise and scalable analysis.

Coverity exists. They've got a great product. But it doesn't solve the problem.

Re: CWE Top Most Dangerous Software Weaknesses

#70

Post by rainonmoon »

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…

Memory safety won't stop you writing SQL queries or dynamically generating HTML that accepts unsanitised user input.
Post reply on HN