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

81–90 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#81

Post by azornathogron »

BoppreH wrote: post #63
Therenas wrote: post #57

Earlier quoted context omitted.

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

URLs are structured. But when you need to send them across the network or store them on disk or even just send them between different processes on the same machine you need to define what the byte level representation is.

I don't see how you can get away from having a defined serialisation format. People try to operate directly on the serialised data using ad-hoc implementations and run into trouble.

But I'm not sure exactly what you mean by "should have been structured". Eventually you've gotta define the bytes if you want to interoperate with other software.

Re: CWE Top Most Dangerous Software Weaknesses

#82

Post by taeric »

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…

You are going to be sorely disappointed with LLMs. :(

We make it look like it is a request response with a chat bot, but it is more realistic to say we are making a single document and having the model fill out the rest. That is, there is no out of band. There is only the document.

Re: CWE Top Most Dangerous Software Weaknesses

#83

Post by BoppreH »

azornathogron wrote: post #81
BoppreH wrote: post #63

Earlier quoted context omitted.

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

URLs are structured. But when you need to send them across the network or store them on disk or even just send them between different processes on the same machine you need to define what the byte level representation is. I don't see how you can get away from having a defined serialisation format. People try to operate directly on the serialised data using ad-hoc implementations and run into trouble. But I'm not sure…

> 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 the current footgun we have, where

    http://http://http://@http://http://?http://#http://
is a valid URL. People don't operate directly on string URLs without trouble either, so at least the structured data is not inviting incorrect usage.

Re: CWE Top Most Dangerous Software Weaknesses

#84

Post by pixl97 »

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?

Re: CWE Top Most Dangerous Software Weaknesses

#85

Post by boveus »

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…

XSS and SQLi can happen independently of the memory safety of your chosen programming language. You can use relatively safe frameworks or ORMs to generate HTML and interact with your DB, but there will sometimes be complex use cases that require you to extend or otherwise not use those safeguards.

Similarly, I imagine that there are cases where someone needs to do complex wood working tasks that involve dangers which are a less obvious than with a table saw.

Re: CWE Top Most Dangerous Software Weaknesses

#86

Post by loup-vaillant »

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…

Safety is nice, but it often costs significant performance. So what you are saying is… if I need performance my only choice is Rust?

Don’t get me wrong, I absolutely hate the insanity of Undefined Behaviour™ in C and C++ (my pet peeve being signed integer overflow), and I’m totally behind systematic bounds checking (which with compile time support tends to lie between free and cheap). I’m less sold on ensuring the safety of memory shared between threads because I tend to prefer message passing, and I’m not sure how to best address use-after-frees: using the general allocator for each and every object is often even more wasteful than just using a GC, so RAII based schemes aren’t quite enough. I have yet to really test Rust’s borrow checker however.

One thing I have noted, is that C, despite its expressive weakness and its unsafe insanity, remains pretty capable at some niches. Low-level cryptographic code for instance is hardly affected by its flaws (having no heap allocation and constant time code helps a ton).

Re: CWE Top Most Dangerous Software Weaknesses

#87

Post by jerf »

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

Earlier quoted context omitted.

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…

Safety is nice, but it often costs significant performance. So what you are saying is… if I need performance my only choice is Rust? Don’t get me wrong, I absolutely hate the insanity of Undefined Behaviour™ in C and C++ (my pet peeve being signed integer overflow), and I’m totally behind systematic bounds checking (which with compile time support tends to lie between free and cheap). I’m less sold on ensuring the sa…

"I’m less sold on ensuring the safety of memory shared between threads because I tend to prefer message passing"

Memory safety, at least to my eyes, has not traditionally encompassed that as a requirement. I don't consider this a solved problem, in that it has a lot of solutions and consensus about them is still developing. (e.g., I still expect async as it has been implemented in Node & Rust to eventually be considered a gigantic mistake but clearly that is not an uncontroversial opinion in 2023; check in with me in 2033 or 2043). So I'd advise trying to use one of the better solutions but I'm not quite to "there's no reason to not use one of these things".

So my passion is mostly about out-of-bounds access and use-after-free. If it costs you performance... take the hit. It's not a lot. And if you do need unsafe approaches, they are almost always some tight loop somewhere or something where you can selectively take the gloves off and drop down to assembler or something. You don't need you entire language to be unsafe just so you don't have to wrap "unsafe { }" around your tight inner loop.

Re: CWE Top Most Dangerous Software Weaknesses

#88

Post by littlestymaar »

tumdum_ wrote: post #19
littlestymaar wrote: post #6

Earlier quoted context omitted.

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.

JavaScript routinely has the other half of the top4.

Re: CWE Top Most Dangerous Software Weaknesses

#89

Post by geodel »

pjmlp wrote: post #50
davemp wrote: post #39

Earlier quoted context omitted.

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

You mean tecnhology like bounds checking, invented during the 1950's decade, with the creation of Fortran, Lisp and Algol, and every other language derived from them, with exception of C, C++ and Objective-C?

And why the whole world wrote so much code in C, C++ and Objective-C when bound checking existing long before these languages without boundcheck?

Re: CWE Top Most Dangerous Software Weaknesses

#90

Post by geodel »

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

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

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