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

91–100 of 131 posts

Re: CWE Top Most Dangerous Software Weaknesses

#91

Post by paulmd »

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.

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 across a couple different region domains and have several different subdomains for different cookie behaviors. It's easy to be clean on paper up until you need to interface with some piece of software that insists on doing it its own way - for example the Azure excel embedded functionality requires the ID token to be passed in the request body, meaning you have to pull in the request body and parse it in your gateway layer (or delegate that to a microservice)... potentially with multi-GB files being sent in the body as well!

It's super easy on paper to start from greenfield and design something that is sane and clean, bing boom so simple. But once you acquire a couple of these fixed requirements, the cleanliness of the system degrades quite a bit, because that domain uses a format that's not shared by anything else in the system, and it's a bad one, and we can't do anything about it, and now that's a whole separate identity token that has to be managed in parallel.

Anyway, you could say that buffer overflow or use-after-free are kind of an impedence mismatch for memory management/ownership in C. Well, XSS and CORS are an impedence mismatch for domain-based scoping models in a REST-based world. Obviously the correct answer is to simply not write vulnerable systems, but is domain-based scoping making that easier or harder?

Re: CWE Top Most Dangerous Software Weaknesses

#92

Post by pjmlp »

UncleMeat wrote: post #80
pjmlp wrote: post #71

Earlier quoted context omitted.

It doesn't solve everything, it solves even less when it isn't used.

Of course. But these issues will remain near the top of the list indefinitely if people just leverage traditional analysis tools. I love static analysis. I did my PhD in it. But we'll still be talking about use after free in 2073 if we just try to chase higher K in our analysis implementations.

Naturally static analysis alone doesn't fix use after free in all possible cases, however it already does fix several of them when the analyser can see everything on the existing source code.

The main issue is the community sub-culture of not adopting tooling as it isn't perfect 100% of the time.

Many of the C++ security conscious folks end up being polyglot, as this subculture eventually wears one out.

Re: CWE Top Most Dangerous Software Weaknesses

#93

Post by witrak »

p-e-w wrote: post #79
rainonmoon wrote: post #70

Earlier quoted context omitted.

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

You're right. Those things are stopped by other tools, such as query builders and web frameworks.

>Those things are stopped by other tools, such as query builders and web frameworks.

No. All tools can be used with an improper attitude which leads to the creation of weak points.

The proper way is to have a deep understanding of the role of design rules.

A programmer who does not pay attention to design (very basic principles of the design process) can create a good game, and even if this game contains weaknesses the risk related isn't a reason to not use it. The same programmer when creating critical infrastructure software is a source of potential nightmare.

Unfortunately, software business accepts such specialists for projects both of kinds. Why? Who knows? Perhaps because of legal regulations? Why when an engineer designs a car they don't try to "Move fast and break things"?

Re: CWE Top Most Dangerous Software Weaknesses

#94

Post by pjmlp »

geodel wrote: post #89
pjmlp wrote: post #50

Earlier quoted context omitted.

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?

It started like this,

"Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own."

-- https://www.bell-labs.com/usr/dmr/www/chist.html

Then source tapes with an almost symbolic license price for its time, and a commentary book did the rest.

Re: CWE Top Most Dangerous Software Weaknesses

#95

Post by waihtis »

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…

I agree 100%, but in reality most people work with the language they are presented with.

Re: CWE Top Most Dangerous Software Weaknesses

#96

Post by amelius »

deadletters wrote: post #59
amelius wrote: post #40

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.

ASan is better for finding memory corruption afaik

Ok. But I'm guessing it has the same problems. I.e., if half your libraries/modules have never seen it, then you'll get a lot of noise. Happy to be proved wrong.

Re: CWE Top Most Dangerous Software Weaknesses

#97

Post by taeric »

BoppreH wrote: post #83
azornathogron wrote: post #81

Earlier quoted context omitted.

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…

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.

Re: CWE Top Most Dangerous Software Weaknesses

#98

Post by PhilipRoman »

amelius wrote: post #40

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.

Valgrind, ASAN and AFL are my holy trinity when it comes to bug squashing. I'm surprised that you have a problem with python modules - I use Valgrind specifically when I need to test executables without recompiling.

Re: CWE Top Most Dangerous Software Weaknesses

#99

Post by j16sdiz »

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?

with bounds checking, out of range index still trigger exception or runtime error. Many of them results in DoS.

Re: CWE Top Most Dangerous Software Weaknesses

#100

Post by j16sdiz »

witrak wrote: post #93
p-e-w wrote: post #79

Earlier quoted context omitted.

You're right. Those things are stopped by other tools, such as query builders and web frameworks.

>Those things are stopped by other tools, such as query builders and web frameworks. No. All tools can be used with an improper attitude which leads to the creation of weak points. The proper way is to have a deep understanding of the role of design rules. A programmer who does not pay attention to design (very basic principles of the design process) can create a good game, and even if this game contains weaknesses t…

> Why when an engineer designs a car they don't try to "Move fast and break things"

They do when they design submersible or rockets

Post reply on HN