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.
I thought I would try and help people out on Stackoverflow.
I posted some code, but AFAICT I could not just post it in , I had to indent every line by 4 spaces. PITA.
I clarified why a user was getting an error message, and my answer was marked down because some anal type thought it was a comment not an answer, and new users cannot comment, only answer. PITA
A questioner added a comment to ask for an extra feature in my answer, and I could not reply to his comment, because new users cannot comment, only answer.
I gave up.
I suspect many people with valuable knowledge to impart will have done likewise, and left Slackoverflow to the anal badge collectors that appear to rule it.
If people simply hired web developers, most web hacking shit would be gone over fucking night.
Thanks for the chuckle.
Java is [garbage collecting ] very s [gc] e [gc] [gc] cure.
The garbage collection [gc] algorithm [gc] [gc][gc] ensures that [gc] [gc][gc] you never know [gc] [gc][gc] when it will [gc] [gc] [gc] crash and [gc] [gc] can't explot [gc] [gc] [gc] common stack [gc] [gc] [gc] pointer [gc] [gc] [gc] bugs.
Also, since java is slow [gc] [gc] [gc]thats another security feature [gc] [gc].
fast programs crash [gc] [gc] too fast [gc] [gc]. Making exploits [gc] [gc][gc] trivial [gc] [gc].
All operating systems should [gc] [gc] be java based. Try [gc] [gc] [gc] hacking [gc] [gc] [gc] something that [gc] [gc] [gc] takes 3 days to [gc] [gc] [gc][gc] boo java expection error.
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.
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?
Not really the fault of the language....
No. It's the fault of the universities that say "This is a great teaching language! We don't have to waste our time on the fundamentals at all! We can just dive right in and start creating classes without understanding niceties like where my variables are actually stored!"
Java is okay for what it is, but if you make it the foundational language for your students, those students will be shite programmers.
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.
If the template is "when you think a question is a duplicate, don't bother checking, just mark it and move on to the next. Don't link to the duplicate, the loser noob should have found it themselves" or "Don't answer a simple question if you can just respond with derision of the language (programming or textual, doesn't matter, but bonus points for both)" or "downvoting to oblivion an answer that, whilst correct, you don't agree with, either by tone, implementation or just because it's Wednesday and you're annoyed about something" then that's not a good base to establish learned behaviour from.
Encouraging such dismissive behaviour purporting as a set of rules and "the way things are done" (a fallacy of a societal norm) to those on the spectrum who are unaware it isn't doesn't help them cope and is more likely to be deleterious to them in the real world.
"Wait. Something's happening. It's opening up! My God, it's full of apricots!"
Yeah, I will confess to not knowing your specific scenario, but I too was faced with a language/library set that had a terrible TLS implementation. I subclassed the plain http class to provide my own tls handling because I know precisely what happens using the default scheme.
This of course drew incredulous response from a security architect that worked on a similar product, saying that I was running a terrible risk by authenticating certificates ssh-style rather than with a CA. I then asked if that concerned him so much, why did his product have a client that allowed user to disable cert validation? He said because users demanded it as soon as they released, and it's the user's fault if that screws them over. I informed him that I didn't provide an option to disable validation, and not one of my users has asked for it. I never could convince him this was a good thing. Note the target market is 99.99% private services not even resolvable by the internet DNS servers. I helped a few of his clients and every last one had hard set it to disable cert validation, and besides I suspect he didn't really understand the underlying way the certificates work, since manually blessed certificates are no more blessed if you use a CA to mark that rather than storing the fingerprints directly.
Too much work in security is about offering a hypothetical possible credibly secure way that no one wants to do, and then offering a feasible approach to get work done so they can blame the users or downstream developers for mistakes. Not enough sentiment of "must make the secure approach also the easy choice".
XML is like violence. If it doesn't solve the problem, use more.
I think there's room for "I've looked at rust, it might be a good idea, but not to the extent it is hyped".
I will concur that I see too many folks saying roughly "oh yeah, Java/Javascript/(etc.) are so much less secure than rust". Those people obviously don't understand *why* rust has the claims about security and/or really piss poor understanding of other languages. It also implies a huge misunderstanding about security in general, that a language design can fix the most usual offenders nowadays (it's generally poor design rather than some sort of buffer overflow or use after free) It is over hyped and way too many people champion it without understanding other than hip to be novel. Hype indeed can inspire a healthy wave of skepticism. Particularly after Go went through just about the exact same hype cycle about 5 minutes ago and has much of the same benefits.
Rust has some decent concepts as a "c-like" language, but with far less tedium around making sure you don't go off into undesired places when your code executes. While most security problems stem from design, there are certainly problems that are still caused by careless mistakes with pointers taken at face value.
XML is like violence. If it doesn't solve the problem, use more.
Perhaps offtopic maybe. The scenario here is indicative of general programmer behavior: easy and functional without looking at the consequences.
The annoyance of runtimes and vulnerabilities in those runtimes are a distinct phenomenon. In fact, I'd say that Java's experience is a good example of the problems of shipping language runtime with your app, which can extend to static linking and providing 'appliance' virtual machines or containers. The lazy mindset that infects java app deployment to cause the phenomenon you see,.. those people will crew up *any* target they may have the exact same way (and sadly this happens more and more, with many libraries no longer making the effort to be api compatible version to version, and pointing to dockerhub in general or virtualenv in python or similar strategies as why it doesn't matter to be compatible and have maintenance streams and other such work devs have no interest/patience for if they are allowed to skip it.)
XML is like violence. If it doesn't solve the problem, use more.
Jesus F Christ on a stick! Think, man, think!
There's a reason there are so few java based root exploits!
Because who in their right mind would give a java app root permissions?
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.
Eh I should have preview my posted, tags got eaten:
Answer: Why in the world would you want to do that? Here do this (unhelpful thing that doesn't answer this question)
Answer: (Complete wrong buggy implementation)
#1 upvote: (Answer that technically works but completely pedestrian, not generalized, etc)
#2 upvote: (mostly the same as #1, but with an added glaring bug)
#4 or #5 most upvoted: (probably the right answer)
further down: (a number of technically correct but a completely stupid ways to solve the problem)
Stackoverflow is the best for people that sort of know what the answer should be and can separate the wheat from the chaff.
I often point to this on as a good canonical example. https://stackoverflow.com/ques...
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.
They're Java coders. Easily replaced.
I tend to rant.
Want to learn to program? Start with C. You can expand to whatever you want after that, but you have to master C first.
I used to say this a lot; however, I was given an analogy that made me change my mind. When we teach people to drive, we don't make them learn on snow and ice. So why should we make them do that with programming?
So, after reevaluating, I decided we should throw out the "Programming 1 & 2" paradigm that so many schools use. Instead, I would like to see:
Programming 1 (in Java or Python): Focuses on logic, syntax, and simple control statements (if, while, etc.)
Programming 2 (in C or C++): Focuses on what was happening "under the hood" in Programming 1, and starts getting into data structures
Programming 3 (still C or C++): Heavy data structures with an introduction to algorithms. This is where they start learning a bit of architecture, compiler theory, and details on how things work. This is not meant to replace an architecture/compiler/etc. class - but to give the foundation so those classes make sense from day 1.
Yes, this means it adds another full class to an undergraduate program, but it also means that capable, interested students don't get blown out of the water because they don't have the background - or are just bad at classwork. It also makes sure that a student does need to understand the details to obtain their Bachelor's degree.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
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.
There are brute force attempts, and smart brute force attempts. Defending against a brute force attack from your kid sister is easy compared to defedning against a brute force attack from the school bully. The quality of security you have depends upon the value of what you're protecting.
If you don't care about what happens if someone breaks your system, then MD5 is fine and it doesn't hurt much of you ask stack overflow for advice. If your company can be put out of business if your back office data can be cracked or spoofed, then MD5 is foolish to use and any developer relying on hint from stack overflow should be assigned to other less important tasks. If you government can collapse and the country invaded if your data is laid bare then hopefully you're so far beyond stack overflow that you're inventing these security frameworks yourself.
You need more than C. I have a lot of C programmers, and most are terrible at software. That's because they're self-taught EE or science types, they understand the low level details but are extremely lousy at higher level abstractions. Ie, they find it difficult to see the big picture of a large software project, they can't make code that other people can maintain or even decipher, and so forth. Their coding skills seem sto be a mixutre of knowing the syntax and combining with a few key rules of thumb.
That said, those that start with a very high level language usuallly have the same problem just with a different view at it. They still only have a few key rules of thumb, this time applied to the few frameworks or libraries that they understand; their code is so chock full of abstraction layers that no one else understands any of it or is capable of make small modifications safely. They think they understand the big picture only because they've labelled it as "BigPictureInstanceFactory".
Somewhere in there are some key skills that are very rare. If you miss those skills you will be lousy at programming in any language or paradigm.
Want to learn to program? Start with C. You can expand to whatever you want after that, but you have to master C first.
I used to say this a lot; however, I was given an analogy that made me change my mind. When we teach people to drive, we don't make them learn on snow and ice. So why should we make them do that with programming?
In an upper division undergraduate CompSci/CompEng course that I teach, I always tell the students, "spent more time reading code than writing code, being able to read code is more important and valuable to a programmer than being able to write code." I have has several students disagree strongly with that assertion. However, I use the example of learning a foreign language.
I know that programming and human language are different. However, I think that the same principle of learning the language structure (e.g., grammar, syntax, etc.) in order to first master reading holds for both sorts of languages. That is, one does not claim to be proficient in Spanish, French, or Japanese based on being able to speak it but not read it.
I was a terrible programmer for a very long time and what finally made the difference for me was to learn how to really read code. Once I had mastered that, I feel like I improved by leaps and bounds. I really wish that reading code had been emphasized as a core programming skill more when I was in school.