Java security plagued by crappy docs, complex APIs, bad advice

if only

... SO provided some mechanism to register the fact that you disagreed with a solution such that the better solution bubbled its way to the top, and a comment box where you could provide a reason for why you disagree.

Its one thing to find code...

Its another to just cut n paste it...

I can tell you that is prevalent everywhere ... and its done by many lower cost resources.

This is posted anon for the obvious reasons....

At one client, I was brought in because of my deep technical expertise.

I had an offshore team (not in India ) who I told them what I wanted, and how to do it.

They refused and decided that it was best to search the web to find a solution. (Which worked but didn't scale)..

At another client, I had a manager ask me to search the web to find an article that covered a topic. I actually offered to write a white paper. (He refused, even though I was brought in for my expertise. )

At another client, I ended up writing something so that the PM on the project could point to it as justification.

Now to be fair, I do a lot of searches because I travel and many of my texts that I use for reference or to learn something new. However, I take the time to see what they are doing and to ask why.

General issue

"They found that many developers don't understand security well enough "

Shocking news, devs. who copied code didn't understand it enough.

Seriously though, this is a common issue which can be seen throughout all areas.

My favorite: Minecraft. "How do I summon a zombie with a wooden sword?". And in come the answers, just too bad that most of them used a so called 'command generator' and said generator hadn't upgraded to the latest version...

The problem: people take things for granted. They hardly question anything these days!

How else do you explain people rooting and donating to projects where you can easily establish that the idea will never work by following up on a 1st class degree physics book?

Coding is no different. Once people find out something works they'll copy it and share it claiming it was their own, even though they have no clue how things work. The worst part:this copying includes flaws.

But how gullable do you have to be to use this stuff without actual testing?

RTFM

In other news, sky blue, water wet.

Security? Sure, we've heard of it.

It's not just Java. It seems to me that most programming languages these days make it easy to create code that is riddled with leaks and problems - and often very hard to spot. Our cut 'n paste programming style propagates minor errors and hides them - and we call this a "feature" aka OOPs.

SO is useful - often as a bad example but there's lot's of good pointers there too if you are looking for a solution. Chances are you won't find the solution but you'll get some good pointers as to where to look.

Too much reliance on third party open source libraries too

I think things are way out of hand with a lot of applications. Developers are way too eager to use every third party library under the sun to do things. How about write a few lines of code instead of pulling in another Maven dependency? I think it is ridiculous. The golden rule that I follow is KISS and don't add tons of dependencies to a project. People just blindly trust the dependencies. When it comes down to it, you have no idea how trustworthy the code is. There is no way you are going to completely review it and if you are getting it from something like Maven, it is constantly changing. One of things I hate the most about Java is the fact that everyone is using third party libraries instead of what is just built into the platform. I.e. using Struts, Spring etc. instead of using standard Java EE. If you don't keep things simple and minimal, you are just asking for trouble IMHO.

This is surprising why. I am among professionals, and it is surprising the way they think. Even the engineers I have to squint the proverbial eye and look hard at them, to see if they are right. I know three international engineers each with good reputation and while I would trust them to do a good job, but feel like their minds are sponge. So even among engineers there are great and otherwise engineers. The problem these days are there a lot of not so great people becoming computer programmers, games maybe to blame. Engineers a bit tougher, you do stuff wrong, people die etc. With application programmers you do stuff wrong, it can cause angst to millions of users and waste so much of their time, it is like lifetimes wasted. But as not many people die from the application bug, it slips people's attention of the absurdity of costing $100's millions dollers of peoples 'lives' on a ten million net profit application. By application I should just say consumer side stuff, including OS's, and not really mission critical stuff. Where are the good people getting sucked up to, higher paid not so productive jobs.

Now, you come along to these professionals, and they give you their 'opinion', based on their experiences and peer impression (a sort of peer pressure I am describing). So, why be surprised when it doesn't turn out right. Much like a doctor that thinks it shines out of his side of the profession, very incomplete competency, but enough to bamboozle other incompetents, and psychologically make the opinion giver feel good, with mistakes transfered to the patient as the source of issues rather than face up to them. But they lack real ability to look into things and think of better solutions. They have formalised memory structures (opinions based on etc) but are not so good at generating new information. It is not as they testify in court, that they did all they knew too, they should know to do more to achieve better (meaning, get off the backside to look into things and establish trurhful extent of certainty). Not being a raving skeptic instead, who just grabs onto things that bolsters his objective, from other people unable to properly analyse them (thinking the sun shines from their crowd and their ideology). (if you see fancy bow ties and suites in an interview, be..warned. There seems to be a certain low grade intellectual psychology at work in these people). Memory of knowledge is not everything, but knowing what to do with it, to also properly understand it. Called wisdom)...

So, you ask people, and you get in a mirror dully, a part answer that somewhat answers it.

Now, I've said this to forum moderators before. What is needed, is to start a wiki of structure knowledge and solutions. Rate the solutions and rate for correctness and issues. Then, when somebody looks up a problem, and then the solution, they have it not only clearly laid out, they have the weight of knowledge of how good and how bad it is, and wherever it just is outdated or should be left alone. Combined with a multiple level programming course, people can find their way around with minimal forum time wasted. It takes time, and people to systematically analyse things and old posts.

Source?

One thing I have noticed about Java is its tendency to bloat by design with needlessly complicated code. Any Java library will suffer from this problem. The bloat makes the code more difficult to understand, maintain, and utilize.

I know it's wrong

It's not just Java.... Googling (I haven't signed their Dev agreement; ) for info on php mysql returns a LOT of code that can be copy / paste and work the way you need it to.

I had to write a service management system as the old one was running on W2K and the upgrade was over £20K. A week later we had a working system. .. I have spent the last several years rewriting it after learning php properly.... slightly more secure now :o

Stack Overflow answers also recommended trusting all SSL/TLS certificates to bypass cert verification errors, even though this disables SSL security checks.

This isn't just a Java problem, it's a problem everywhere. A disturbing number of people using the Forge Javascript TLS library, for example, write code that responds to verification error callbacks with "return true;" Likewise almost everyone configuring a WPA2 Enterprise network on Linux turns off certificate verification, because configuring it to work is non-trivial, especially when the connection you'd use to download the cert is the same one you're trying to set up.

This is really tempting when you're just trying to make things work, especially when your code lacks access to the system's certificate store, but honestly it should be seen as utterly unworkmanlike. It's the sort of coding habit we may just need to shame people out of.

Copy and paste Jedi

I have a couple of coworkers with Jedi grade copy and paste skills. They can create an entire project, with full unit tests, that is copy-n-paste-with-changes from another project. It looks so legit that it passes peer review by others. There were some awesome tricks to faking the unit tests. One coder's unit tests consumed a huge amount of sample data through a source that was, through roundabout means, a singleton iterator with one value. The first unit test validated that data existed. After that, the iterator was depleted and all other very complicated looking unit tests were no-ops. Another coder used a stubbed method to generate a NullPointerException while initializing each test, and then caught that exception in a misleading way using incorrect indentation.

Remove MD5?

Obviously using MD5 for security purposes in a new application isn't a great idea, but it's still a commonly used hash, especially for legacy purposes. Completely removing it will just lead to people using crappy 3rd party implementations, which would be worse for security in the end.

SO Isn't Evil and Java Is Not The Problem

I agree that SO is not documentation, and that you can't rely on anything someone posted there at face value. However, it provides indispensable advice that is the result of crowdsourcing. I rely heavily on SO simply because I typically find good advice there. I also contribute occasionally and, once in a while, say something stupid. Generally, that gets downvoted in a hurry.

Java != JEE, and Spring is an independent framework. Java does not have large security issues, apart from browser embedding. JEE is too complex, but I don't hear about security issues. Spring is great, but the documentation is thin, and security is always hard. However, even though I don't work in security, I know enough to check which standards are up-to-date and secure and not to bypass security features in Production.

The article made some valid points, but, overall, it seems a bit biased.

Stackoverflow already have a recommendation on this issue

How to Warn of Serious Issues in Code Unrelated to Question?

https://meta.stackoverflow.com/questions/266339/how-to-warn-of-serious-issues-in-code-unrelated-to-question

Answer: Just leave a big bold Warning comment for future readers

Having read some of the pdf - why would this article be titled "Java Security ..." ? This is to do with various frameworks like Spring, and libraries like Bouncy Castle, etc. A better title might be "Java libraries have security issues when coupled with bad programming practices" but that is not as sensationalist.

Java plagued by crappy docs, complex APIs, bad advice

there - ftfy.

SO is only as good as we all make it...

... so the correct thing to do is add the updated information, explaining why earlier answers are out of date, and let it all sort itself out. The best devs will find the corrections, karma will deal with the rest eventually.