Slashdot Mirror
Java Coders Are Getting Bad Security Advice From Stack Overflow (helpnetsecurity.com)
Slashdot reader Orome1 quotes Help Net Security:
A group of Virginia Tech researchers has analyzed hundreds of posts on Stack Overflow, a popular developer forum/Q&A site, and found that many of the developers who offer answers do not appear to understand the security implications of coding options, showing a lack of cybersecurity training. Another thing they discovered is that, sometimes, the most upvoted posts/answers contain insecure suggestions that introduce security vulnerabilities in software, while correct fixes are less popular and visible simply because they have been offered by users with a lower reputation score...
The researchers concentrated on posts relevant to Java security, from both software engineering and security perspectives, and on posts addressing questions tied to Spring Security, a third-party Java framework that provides authentication, authorization and other security features for enterprise applications... Developers are frustrated when they have to spend too much time figuring out the correct usage of APIs, and often end up choosing completely insecure-but-easy fixes such as using obsolete cryptographic hash functions, disabling cross-site request forgery protection, trusting all certificates in HTTPS verification, or using obsolete communication protocols. "These poor coding practices, if used in production code, will seriously compromise the security of software products," the researchers pointed out.
The researchers blame "the rapidly increasing need for enterprise security applications, the lack of security training in the software development workforce, and poorly designed security libraries." Among their suggested solutions: new developer tools which can recognize security errors and suggest patches.
The researchers concentrated on posts relevant to Java security, from both software engineering and security perspectives, and on posts addressing questions tied to Spring Security, a third-party Java framework that provides authentication, authorization and other security features for enterprise applications... Developers are frustrated when they have to spend too much time figuring out the correct usage of APIs, and often end up choosing completely insecure-but-easy fixes such as using obsolete cryptographic hash functions, disabling cross-site request forgery protection, trusting all certificates in HTTPS verification, or using obsolete communication protocols. "These poor coding practices, if used in production code, will seriously compromise the security of software products," the researchers pointed out.
The researchers blame "the rapidly increasing need for enterprise security applications, the lack of security training in the software development workforce, and poorly designed security libraries." Among their suggested solutions: new developer tools which can recognize security errors and suggest patches.
You mean advice from people who spend more time hanging out on Stack Exchange and less time actually writing production code is turning out to be less correct than advice from people who talk less and do more? Color me surprised. (Not.)
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
News flash, heavily simplified programming snippets for the purposes of example and education are probably not suitable for a production environment.
Coders today are completely lazy, don't give a fuck about doing anything other than writing code and meeting goals. Management didn't tell them to do it? They don't fuckin' do it. I grew up developing web sites and web apps and learned security the hard way ...getting fucking rooted dozens of times! when I started doing development for money I had to make sure someone couldn't just bypass security controls and hack the customer's sites and when they did, you bet your ass i had to FIX IT. It should be obvious to anyone with a fucking pulse that as soon as you put a site online, SOMEONE WILL ATTEMPT TO BREAK INTO IT.
When I got my first professional IT job as a developer, I had to be aware of security on publicly exposed web sites. I had to understand basic concepts such as how requests are handled, how variables are managed, preventing SQL code injections. When I came across vulnerabilities it was my responsibility to communicate that to management and GET THEM FIXED. Oh what you wanted the new company site live thursday? Fuck that, but i'll see what I can do AFTER we fix these other issues. You know something? Not once was I ever told NOT to focus on a major issue when I found one. Those were the "Good old days" - working for a small not-for-profit of all things.
Now, as an IT "Engineer" I manage systems, not code and it's not my place to open my big fucking mouth every time i see something so cringeworthy, i want to just jump out the fucking window. Our fucking developers don't even understand how mother fucking SSL works. I'm NOT MAKING THIS UP. "I don't have time to learn that." they actually say this! Here are a bunch of highly paid professional fucking developers and they don't even know how SSL(ok, TLS now) WORKS ...and here's the kicker, to them, it's not even THEIR FUCKING RESPONSIBILITY to know. Their job is writing code. If two web services can't talk because they don't know how certificate based authentication works, that's not their problem ...to them that's a system problem. How the hell do you think they're going to approach security and vulnerability management?
Is it any surprise then that these very same people don't give one fuck about security, much less even understand the impact of a security vulnerability might be? Hack after fucking hack, all of our personal and private information is being stolen and sold and it's because of people like this. People whose job it is to write code, and whose job it IS NOT to give even a single solitary fuck about security.
Now your typical enterprise may have third party security assessment and penetration testing - which is OK, but most of the time it's testing well-known exploits. The average exposure to vulnerability remediation an enterprise developer gets is putting a ticket into the engineering queue to ask them to modify the load balancer/WAF to add "httponly" and "secure" flags to the fucking cookies. That's when the company starts blowing millions on software and tools to do the work for you, but we all know the buck's gotta stop somewhere. Don't professional enterprise developers have a goddamn duty to be aware of these things and to put the time and effort into avoid such common fucking failures?
When I've had to make a quick judgment about a programmer's knowledge and competency, I've found that there's one simple question to ask that works wonders:
"What do you think about the Rust programming language?"
Some people will say, "Rust? What's that?". These are typically unskilled people who probably don't know more than elementary JavaScript or PHP. I tend to ignore these people going forward. They're not worth my attention.
Other people will say, "Rust! Rust is fantastic! It's so safe!". These people are typically hype-loving suckers. They've heard of Rust, probably at Hacker News or Stack Overflow, and have bought into the hype about it. They want to come off as "trendy", so they talk about how great Rust is. I tend to ignore these people going forward, too. I don't want to deal with small-minded people like this.
Others will say, "Rust... I tried it. I was not impressed." These people can be respected. They have up-to-date technical knowledge, and they're willing to try new technologies, but they're not blinded by hype. These people are worthy of consideration. One thing to be aware of is that they're neutral about something they should not be neutral about. There are just some things that people should have strong negative feelings for.
Finally, the most intelligent will say, "Rust? Fuck, no. I use C++." These are the people to take seriously. They aren't just neutral about Rust. They actively dislike it. This means that they've probably got a thorough understanding of Rust and its flaws. What's more, they clearly know that C++ is a better alternative, and actively choose to use the best option available. These people get my attention, and I respect what they're saying.
It's really surprising how much insight you can get about somebody from such a short and simple question.
If stack overflow supported nested comments, these "security experts" could post corrections for the insecure code, kinda like how you can correct someone on slashdot. It's pretty stupid to not support nested comments in 2017 (and not the tiny font remarks SO currently uses that make them unsuitable for code).
I've actually studied this at length, and even read a few treatises on the subject. Short answer: nope. Nested comments pretty much suck.
Nested conversations (like those here on slashdot) don't actually make conversations better. They just splinter the conversation into a thousand shards, each of them relatively short, and rarely on topic. They also promote shitty quoting habits and make it difficult to pick up a conversation where you left off without re-reading the whole damn thing.
Flat, linear comments tend to stay on topic, force people to quote properly, and are ordered properly with respect to time.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
If people simply hired web developers, most web hacking shit would be gone over fucking night.
No. Just no. The only thing worse than Java programmers are web developers.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
So, I agree with all the haterade at SO and all the things it does wrong and stuff. But let's take a moment of reflection and see if maybe we as a community also did something wrong.
My opinion is that it's a total lack of actually useful documentation. And by that I mean there's almost always documentation, but it's at a level of specificity that makes it totally useless.
By way of analogy, imagine getting into an airplane and there's tons of man pages for each instrument like "The throttle control the amount of forward thrust generated by the engines. It has three auto-throttle modes for speed, trim and power, you can enable those modes by setting the auto-throttle switch to the ON position and adjusting the rotary dial to the desired mode. The power mode cannot be used while the autopilot for level is set."
And so on there's documentation on every little thing but nowhere does it actually explain how the hell to fly a plane.
There are projects whose documentation is exactly like this. They are full of great (and useful) detail about how the parts work but there is no place that explains how the whole project works at a general level and how to get it off the ground.
There are two ways to view programming, both of which are very important to understand. There is an abstract model view of programming, and that's what Java could be good at. Except that something like Scheme is ever better at this. This is supposed to be a high level view of what what algorithms actually are as a concept, rather than the implementation details at a machine level.
But you also need the low level view, how things actually get done. If your only model of a program is a bunch of magical black box operators that all take 0 time and space, you can't think well about the problem. Big-Oh notation is meaningless if you don't know what you're measuring. Missing this knowledge is a major hindrance, and yet so many don't realize they have this flaw.
You certainly won't be any good at even basic security without having both an abstract and a concrete model.