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.
Not really the fault of the language....
Of course the secure 'solutions' should take note that something is deeply wrong with how they go about providing secure options when this happens so much.
People don't do this because they like being insecure, they do it because it's easier.
Disabling CSRF is popular because it's *generally* implemented in a pain-in-the-ass way. Not only in a pain in the ass way, but it seems every five seconds another framework comes up with a slightly different approach to CSRF that isn't any better or worse than the myriad of approaches already. One massive improvement on that front in general would be to disable all that crap if no referrer is set at all, which would solve 99% of the situations where people feel compelled to weaken CSRF protection (non-browser automation).
There are two accepted approaches for TLS if you are note doing things for internet sites: Maintain a convoluted CA setup or if you can't bring yourself to do that, well, disabling it is the only other easy way provided. In my software I tend to provide option of treating TLS software similar to ssh known hosts if CA verification is not an issue, and users are never bothered, until something does go awry.
Using obsolete communication protocols and hashes is generally the consequence of having to interact with data or equipment or older setups. Sure some of it is just people got taught that specific way once upon a time directly addressing low level crypto functions, but a lot is intentional. Of course this is a problem that propagates, new interface to old setup uses old protocol, new thing to talk to new thing, well might as well use old protocol there.
XML is like violence. If it doesn't solve the problem, use more.
I'm a veteran of the software industry (3 decades, now) and regularly screen, interview, and hire software engineers -- mostly college grads, some with a few years of experience in the industry. I can tell you with absolute certainty that Java programmers -- those who primarily learned Java in college -- are easily the worst programmers I encounter while hiring. And to date, I haven't hired a single one of them, even though I've talked to and interviewed countless numbers of them.
Want to learn to program? Start with C. You can expand to whatever you want after that, but you have to master C first.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
Of course Rust code isn't often exploited. Nothing important has actually ever been written in Rust! It's damn near impossible to exploit software that doesn't actually exist.
It's excusable that there are holes in some C code. Much of this code was pioneering, and didn't have the hindsight of experience when it was being written. A lot of C code actually predates the widespread use of networking.
Of course, many people and organizations what would have used C in the past now use Modern C++. While Modern C++ does allow you to write insecure code, it's actually quite difficult to do. As long as you use the STL template algorithms and classes, and as long as you use smart pointers, your code will be quite safe.