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

111–120 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#111

Post by waihtis »

paulmd wrote: post #91
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.

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

Great examples. 1) You have to deal with your own complex systems where it becomes difficult and 2) you have to deal with external complex systems which enforce bad practice on you. One can see how it becomes borderline impossible not to slip once in a while.

Re: CWE Top Most Dangerous Software Weaknesses

#112

Post by taeric »

BoppreH wrote: post #107
taeric wrote: post #97

Earlier quoted context omitted.

Your certificate isn't entered by hand, though? That is, it is easy to see that the reason we have URLs sent as strings, is that we collect them from the user. And it makes perfect sense that we would collect strings of characters from users.

How many URLs, as a percent of all browser navigation, do you think are typed by hand? And I don't mean "news.ycombinator.com", I mean the full URL, like " https://news.ycombinator.com/news ". And in those rare cases, of course you can collect strings from the user. But then they have to be parsed, and that's what should be on the wire. IP addresses are also sometimes entered by hand, but we don't send those strings…

Fewer today than when it started, for sure. Though, I'm not clear that "copy pasted between applications" doesn't have its own problems. I have never seen that done in a "you are passing objects around" way that didn't have terrible security.

Re: CWE Top Most Dangerous Software Weaknesses

#113

Post by tumdum_ »

jerf wrote: post #78
loup-vaillant wrote: post #51

Earlier quoted context omitted.

So, the memory related ones are in position 1, 4, 7, 12, 17, and 21. I understand memory safety is important, but still: only one in the podium (though it is first), only 3 in the top 10… clearly security is about much more than memory safety.

This isn't about choosing security measures from a menu. This is about the foundations of what you build. To the extent that memory safety is slowly, oh so slowly, but steadily dropping down the list, it is because we are taking it seriously as a foundational issue and actually addressing it. To turn around and then use the success we've had as evidence that it isn't important is making a serious error. There is no r…

> There is no reason to use a memory unsafe language anymore, except legacy codebases, and that is also slowly but surely diminishing. I'm still yet to hear this amazingly compelling reason that you just need memory unsafe languages. In terms of cost/benefits analysis, memory unsafety is literally all costs.

Tell that to the authors of new memory unsafe languages (like Zig) and creators of new projects in those languages (like https://tigerbeetle.com) :(

Re: CWE Top Most Dangerous Software Weaknesses

#114

Post by BoppreH »

sigstoat wrote: post #104
BoppreH wrote: post #83

Earlier quoted context omitted.

> I don't see how you can get away from having a defined serialisation format. Yep, that's exactly it. Your TLS certificate is not sent as string, and neither are your TCP packets, nor the images contained in them. Your URLs shouldn't be either, but it's probably too late for that. > People try to operate directly on the serialised data using ad-hoc implementations and run into trouble. That's a whole lot better than…

> > I don't see how you can get away from having a defined serialisation format. > Yep, that's exactly it. Your TLS certificate is not sent as string, and neither are your TCP packets, nor the images contained in them. ...all of those things mentioned have defined serialization. i expect all of them have had security issues because of problems with deserialization code.

Yes, of course. Everything that is stored or transmitted must have a defined serialization. And any piece of code as widely used as this is going to have security issues.

What is your point? That strings don't need defined formats? That they have less security issues?

Re: CWE Top Most Dangerous Software Weaknesses

#115

Post by nojvek »

davemp wrote: post #39
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…

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

Wow! SawStop is incredible tech. the blade stops within 5ms. That's insane.

Re: CWE Top Most Dangerous Software Weaknesses

#116

Post by timbit42 »

pixl97 wrote: post #84
matt2000 wrote: post #64

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…

So you want to be a licensed engineer to write software?

This will eventually happen.

Re: CWE Top Most Dangerous Software Weaknesses

#117

Post by stusmall »

heelix wrote: post #24

Mitre really lost a lot of respect with CVE-2016-1000027. Every few weeks a warning that any SpringBoot 2.x project has a CVSS 9.8, which causes all sorts of heartache for those of us bound to CVE remediation. Every blasted security tool reports this one. Spring reviewed and rejected, as did our very, very large organization. Comically, this has become the CVE we use to see how our tools allow us to white/black list…

What would you rather? It seems to make sense to rate these with such a high CVSS. All auditing tools I know of have a way to whitelist CVEs to say either "We've looked into this and it doesn't impact us" or "We are willing to accept the risk". From your post it sounds like you in the first camp, but others might not be and need those notifications.

RCE via deserilaization seems valid 9.8 even if it requires the developer to use less common APIs or using them in strange ways. In the bug they have a comment that the documentation warns about these API but that doesn't really impact a CVSS score. Am I missing something about this specific CVE on why you think its unfair?

Re: CWE Top Most Dangerous Software Weaknesses

#119

Post by sophacles »

pixl97 wrote: post #65
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.

Some humans think in strings. I don't, generally I think in pictures.

Re: CWE Top Most Dangerous Software Weaknesses

#120

Post by gemanor »

rtev wrote: post #101
gemanor wrote: post #34

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

Typescript applications suffer from many of these vulnerabilities. JS apps have a specific class of critical vulnerabilities as well, prototype pollution. If I had to write a web application with security in mind, I personally would pick Python. It’s possible to make mistakes in any language though, and the environment an app is deployed in can independently introduce many vulnerabilities.

When I wrote typescript, it was half a joke as a result of the language ranking in one of the comments. As you said, the most important factor is the platform, not the language itself. Writing the software in a language that run well on the platform you aim for, is the right decision.
Post reply on HN