Discussions

Ted Neward has written a scathing rebuttal of the recent Java Developer's Journal article on Java Security. He walks through the points made, and tells us in his own special way, what he thinks it totally incorrect :)

Introduction

Recently (Volume 9 Issue 4: April 2004) Java Developer's Journal ran an article on Java security that I just found myself virulently (and violently--I had to spackel over the slight divot in the wall that the magazine corner made when hurled against the wall with great force) disagreeing with. Naturally I now foist my arguments upon you, my faithful blogaudience....

The basic upshot is simple: I sincerely believe these three authors were more interested in showing off how smart they were than in genuinely helping Java code authors. Otherwise, how can you explain an article on Java security that never once mentions the AccessController/SecurityManager, JAAS, Permissions, or policy?

The fact that we have an access specifier called "private" has absolutely NOTHING to do with security. Yet everyone is talking about how important it is to secure instance data by making fields private. What nonsense is that?

Choosing the proper access specifier is an OO encaptulation issue, not a security issue. Three lines of reflection code is what it takes to get "private" data anyway...

Ted has pointed out regarding one article on so called Security.However this also reflects a larger problem with JDJ.

The quality (& content) of articles in JDJ has been on the downhill for a while now. For a magazine like JDJ that charges for its content, it is pretty weird to adopt the policy "writing is the reward by itself".

Consequently JDJ has become a magazine with articles "by newbies, for newbies and of newbies" (with exceptions once in a while). Nothing wrong with that. Even first timers have great ideas and articles. But there is something called filtering the content to maintain the standard of the magazine.

For whatever reason, there are two categories of articles that appear in JDJ these days.1)Articles such as "Java basics", "OO and Polymorphism". This forms the majority. (Come on. Java has grown up. We need something more serious than this.)2)Product promotions veiled as articles

For whatever reason, there are two categories of articles that appear in JDJ these days.1)Articles such as "Java basics", "OO and Polymorphism". This forms the majority. (Come on. Java has grown up. We need something more serious than this.)2)Product promotions veiled as articles

I agree with Ted, the article truly sucked. Without covering such things as JAAS, JSSE and classloading it misses the main and perhaps easiest ways to make a Java application secure.

I will go out on a limb and take issue with some of his rant however. He says some things that I think are a bit odd and I think he's missing something.

"3. Make your classes noncloneable. Cloning isn't turned on unless you implement the Cloneable interface anyway, last time I checked...."

Check again: I can make a class cloneable simply by overriding the clone() method of Object. Cloneable is a marker interface. Making a method non-cloneable means to explicitly through a CloneNotSupportedException if this method is called. This also guards against a superclass that IS cloneable, but one that you don't have the source to. Of course you don't need to do this if you do want your class to be cloneable, for some architecturally significant or design reason.

"Make your classes nonserializable. Serializability is an issue all its own, best addressed by Joshua Bloch's Effective Java. Simply saying "make them nonserializable" is nonsense, particularly since you have to opt-in by implementing Serializable in the first place. Moreover, they completely ignore that an attacker can always look at the internal state of any object, serializable or not, using Reflection, assuming he has code that's executing with the proper permissions."

Uhm, kinda the same as the Cloneable argument above, Check again: Once again a marker interface that can be implemented by a superclass that you have no source to. Guard against it the same way you do Cloneable - explicitly implement the readObject() and writeObject() methods of Object and have them throw an exception.

"5.Do not depend on package scope. You would almost think from their article that Sun just sort of let package scope "happen" by accident. And what about protected scope, which permits access by the package as well? That's OK, but package-level isn't? "An attacker can simple add another class to your package and then access package-private fields that were supposed to be hidden." Yep, and if the attacker can simply add another class to your package, chances are he can replace your code of the same name in that package. You guys are looking for attack vectors that simply don't exist.... Look, this, and #2 and #3 and #4 are all essentially worthless, under the principle that "if the attacker can inject code into your system, you're done anyway...."

There are lots of ways and reasons to inject a class into a package to obtain the package scope variables without replacing the original - like say eavsdropping on an applet in your local VM? Anyway, perhaps I'm an old C++ guy, but I have never seen the utility of package scope so I never use it anyway. And just because Ted can't think of a reason to do this, doesn't mean someone else hasn't. Those are attacks that can be used to gather information when you don't have the source code.

I still think these are very good coding practices and should be encouraged and not ridiculed by someone of Ted Neward's noteriety. Whether by mistake or by design, this diatribe seems to indicate you don't have to do any of this or the other stuff (making classes and methods final, avoiding returning internal references, keeping stuff private etc) and you can still have secure code. I think that's just about as bad as saying that's ALL you need to do (as does the JDJ article in question).

Of course you should do all that stuff. Not just a few, ALL of it. Don't make it easy for a would-be attacker. And, like Ted says, it won't matter much if the your code does not take advantage of SecurityManagers, policy files, permissions, obfuscation, sealed jars, preferred classes lists, JSSE and crypto to add security. Do it all. Make it so difficult to "hack" your code, that the "bad guys" will move on to somebody elses code.

Now. by the looks of the other comments here I'm gonna be flammed big for this but I don't care. Ted may not see the danger in some of these recomendations, but I think that kind of defensive coding will only strengthen your code. And who know's, it may prevent an attack no one has everthought of.

As long as you want shallow (memeberwise) cloning, then Ted's statement is 100% correct.

And you can't make an object cloneable by just overriding the Object.clone() method; you have to call super.clone() from the overriding method. And guess what happens if you're not implementing Cloneable? That's right, it will bomb with a CloneNotSupportedException.

If you don't implement Cloneable, and consequently can't call super.clone(), then the only way to clone the object is by calling a constructor with new. But if a client extends your class, it will get the wrong class type when it calls super.clone(). That's why Object.clone() is native, because it creates a copy of current object without using a constructor.

The Cloneable marker interface is just bad design because its tightly coupled with the semantics of a protected method in the superclass. So from a client's perspective, it's useless.

It's good to see someone who puts aside professional hurbris and admit they made a mistake. I think some folks at TSS should learn from this and drop the condescending, holier-than-thou zealotry I've been reading here for 4 years.

(Yes, I have been posting here for about 4 years, despite my 'new' status. I stopped posting in disgust after the Petstore debacle and, of course, lost my old ID....)

Joseph,It's good to see someone who puts aside professional hurbris and admit they made a mistake. I think some folks at TSS should learn from this and drop the condescending, holier-than-thou zealotry I've been reading here for 4 years.(Yes, I have been posting here for about 4 years, despite my 'new' status. I stopped posting in disgust after the Petstore debacle and, of course, lost my old ID....)Anyway, sorry for the rant and thanks again.Mike

Very good reply. I accept all of your points. I was just trying to point out in my rebuttal that it certainly doesn't hurt to do all those things in order to have as much "security" at every level as you can. I did get the impression that you were discouraging the practices mentioned, even though now I know that was unintentional. I just want to make sure that some of the less experienced among us realize that code security involves those things mentioned in the JDJ article in conjunction with policy files, class loader security, JAAS etc.

And I just want to be clear that my " condescending, holier-than-thou zealotry" was not aimed at you in any way. You actually put up some good arguments, I replied to clarify, you rebutted to clarify even further. That's the way these forums are supposed to work. As I indicated I haven't been on here in a while and in getting caught up in the last few weeks, I have noticed a lot of 'ra-ra my way is the best way, you other guys suck' type of responses in a great many threads. And I find that disturbing, since the TSS used to be the place for sensible debate and exchange of information, where that kind of behaviour was usually relgated to Rolf Tollerund ( ;-) ). Now it seems to be more common, almost like TSS is turning into Slashdot or something.

Anyway, keep up the good work. Perhaps the next step, instead of a rebuttal, is for one of us to write a 'real' Java Security paper to post here or send to the JDJ for publication. One that covers the right stuff. I'll have flip through Scott Oaks book and some of my code and see what I can do....

Perhaps the next step, instead of a rebuttal, is for one of us to write a 'real' Java Security paper to post here or send to the JDJ for publication. One that covers the right stuff. I'll have flip through Scott Oaks book and some of my code and see what I can do....Mike

Hi, guys. I posted a public reply on http://epesh.blog-city.com/ - Ted's pretty much right about that particular item. Sorry about that.

Joseph thinks that the security article is a "mea culpa" and otherwise things are okay at JDJ. I strongly disagree. I think the problem is bigger as I pointed out in an earlier posting here.

I am one of the Server Side commenters on JDJ that you pointed to be saying "this is the kind of crap JDJ prints now". Those were not the exact words. But anyway you summarized it well.

My comment about JDJ articles of being "OO and Polymorphism" are sometime back. I have stopped reading JDJ since then.

I just pulled up Issue 3 and Issue 4 of JDJ before writing this feedback. I see articles with no depth - just skimming the surface - and a whole lot of them. Let us take an example.JAXB for Enterprise Applications. It looks to be one of the feature articles in this issue (Issue 4). Yet it is a page or two. It goes like: Here is the API. Here is how you use it. alright Bye bye.Any decent developer can figure it out by reading Sun's tutorial. You dont need an article on that. Sun's tutorial is does that job.

If I wrote a article, it would be something like this:

The problem: XML to Object conversionForces: Configuration needs it, Web Services need it, other places neededSolutions available: Castor, JAXB, DigesterCompare and contrast each of them.Describe each of them.Describe several scenarios and which one is suitable in each scenario. What are the shortcomings of each. Showstoppers in each.And each of the above categories in detail.

As you can see writing an article like this requires a lot of research, a lot of homework from the author's part and not just some scribble over lunch time.When the readers read such an article, they will read it with interest. There will be a sense of contentment after reading it.

So, here is my suggestion: Instead of running pointless interview with the manager of a product team or a dozen articles scratching the surface,just concentrate on getting two or three articles of the fashion I pointed out and see for yourself how the developer perception changes.

In the changing world and maturing Java, I feel JDJ needs to change. JDJ cannot be everything to everybody. Yet this is how I think it should be and lot of people will agree with me.

You said I thought "everything was okay at JDJ." I'm not sure where you got that - maybe by the implication that I think things are better at JDJ than you do.

I'll stand by that, sure. But not that "everything is okay at JDJ." I don't think there'll ever be a condition where stasis is acceptable. In fact, I'd say the article indicated a few internal things, and the JDJ editors are certainly actively talking about it, trying to find a constructive solution. I'm not sure what it'll be yet, but we'll get there, I think, because optimism is hard to kill.

I appreciated the feedback, and pointed it out internally (like I said). I welcome any commentary, positive or not, and I'm not afraid to be honest about things.

For the future, though, please refrain from making my conclusions for me - especially when the conclusions you make for me are wrong. :)

"Everything is okay at JDJ" was a wrong choice of words from my part that significantly altered the meaning and is misnterpreted. I apologize.

What I meant to say is :You implied other articles at JDJ are OKAY except for this one. This is evident from the following statement in your blog - "This article got skimmed by me..."They may be technically OKAY - like the example I gave earlier.That article did not have technical glitches.But the question is: How useful are those articles?If they aren't useful are they OKAY?

That is what I meant to convey.

However I did NOT draw conclusions for you. Neither would I want to. I am sorry if my comments made you feel so. But those comments were my 2 cents based on genuine interest to help improve JDJ.BTW, I appreciate you voluntarily taking out time to go through countless articles that are slammed on you. I VERY WELL know being EiC is an endurance test :)

I dont have much to say since you feel breadth is more important than depth for the magazine. Let us agree to disagree on this issue :)

As for your suggestion for me to make an attempt to write an article like that: I have news for you. I wrote the first cut of that article last year. It is part of my forthcoming book. Also having written a couple of articles myself (which I think were depth oriented. It is for others to judge), I very well know how difficult it is to write an article with such depth. It took me more than a month to write the above mentioned stuff!!!

That's why I said: Publish two to three articles with depth. But hey! we are already on diagreement on that one.

Again, be very careful. I appreciate your apology - no offense intended, none taken - but I'm neutral about whether JDJ is depth-first or breadth-first. I personally prefer depth, but changing a magazine's core format is not an exercise for the uncommitted.

That said, I'm willing to do it if - and only if - it has meaningful reward. I'm afraid I don't have a lot of experience in publishing, so for me, such moves are made very cautiously.

There are a lot of issues to address. I'm trying to address them. Because of the structure of JDJ, we get a lot of breadth-first articles, which obviously limits the number of depth-oriented articles we get. I'm certainly not averse to authors writing things that fit, as I've said before (on my blog and on Javalobby).

I still think this article is a secondary symptom (and yes, that means I think things are far from "okay" at JDJ - but I also don't think the sky is going to fall.) Reading it in print, my thought was, and I quote, "Oh, crap." That, in itself, isn't a big deal - but the fact that it got through is.

I personally prefer depth, but changing a magazine's core format is not an exercise for the uncommitted.That said, I'm willing to do it if - and only if - it has meaningful reward. I'm afraid I don't have a lot of experience in publishing, so for me, such moves are made very cautiously.There are a lot of issues to address. I'm trying to address them. Because of the structure of JDJ, we get a lot of breadth-first articles, which obviously limits the number of depth-oriented articles we get.

I am no editor and I dont know how it works. But I have a suggestion for an experiment you can try out without too much risk. You can do this if an established image isnt important to your magazine.

1. Lets say you select an issue in the future (say Oct 2004) and earmark it for depth first articles. 2. Invite articles from authors by setting pre-requisites - content type, no of words. conent quality, depth etc. (The number of words itself will be a deterrent to folks not serious about writing)3. Set aside a few pages towards the end of the magazine for intro articles on emerging technologies (those are always needed to introduce the reader to a new technology on the horizon)4. Thereafter continue your issues in the normal fashion as they are now.5. In the meanwhile extensively gather reader's survey on the changed format

Obviously I am not qualified to even estimate the behind the scenes logistics of this experiment. So, take it or leave it.

Another added benefit is that It will save you from having to filter through countless "me-too" articles.

I'm currently a subscriber to JDJ, but after this subscription expires I'm not likely to renew. The main reason is that I miss in-depth articles that teach me things I don't get elsewhere.

Back in 1988, when I was seriously learning C and Windows, my main magazines were C Gazette (still one of my favorites), Microsoft Developers Journal, Dr. Dobbs and the magazine Jeff Dunteman published (sorry, the name escapes me).

Now it's the late 90's and I'm mostly doing management and very little coding. 2002 and management positions are more scarce. I decide to retrain and learn Java and server-side development.

Not unsurprisingly, the landscape of magazines has changed a bit - and in my opinion not for the better. Old classics like Dr. Dobbs seem to cover less in-depth than before. The magazines are much lighter than I remember and I'm not getting what I'd hoped for.

Forums and blogs now compete with established magazines. Discussion forums help validate the points discussed in articles so it's easy to know what to avoid.

I don't envy your position. If your desire is to cater to the new developer, then I wouldn't change a thing. For myself, I'm looking for information I can't get anywhere else.

I strongly agree. Over the last year, JDJ's focus has become less hardcore. Veteran or mid-level developers are not going to find it as attractive as it used to be. What a pity.

Regarding another post here about the JAXB article, those were my feelings exactly too and it is symptomatic about the shift in JDJ's focus. There are a zillion tutorials/articles out there that tell you what JAXB is.

JDJ filled the need earlier for the hardcore Java developer's magazine. Now they have shifted focus so the need is there again. Does TSS want to fill that need? How about TSS coming out with a hardcode Java developer's magazine? I am sure it would sell. Just target the right market (hardcore Java developers) and do not go for mass market. I am sure there are people willing to pay for the right stuff.

Lots of issues here. Plagiarism is a serious charge; what ended up happening is that some fairly common "security tips" got published as a core article. It was insufficient on a number of levels, and for a number of reasons.

I don't know about JDJ "retracting" an article. I considered that already, but that's sort of like "unspilling" milk; the article's been printed, and the suggestions, while not always complete or necessarily as valid as I'd have liked, are still fairly accurate.

Regarding in-depth articles, that's been discussed heavily, as well. If TSS would like to enter the print market, well, come on in - it's a highly competitive market, and I wish all of our competitors well. We certainly don't want to abandon a market sector - and we're certainly interested in soliciting articles of greater depth. In the absence of a "techie's journal," please feel free to write anything you think others would like to read. We try to publish what is best out of what's been written; if nobody's written something of sufficient depth, well, it won't get printed as something of sufficient depth.

Lots of issues here. Plagiarism is a serious charge; what ended up happening is that some fairly common "security tips" got published as a core article.

I find this explanation seriously lacking. To simply claim that "some fairly comment 'security tips' got published as a core article" is to claim that "mistakes were made" and "people were upset". This is a huge embarrassment for any publisher, I understand, but Joseph, those tips read almost word-for-word identical.

I contacted Gary McGraw (someone whom I consider a friend) about this when it was brought to my attention, and he's promised to look into this. Apparently this isn't even the first time this has happened with this material, though I'll leave the details out for now.

Joseph (if I understand correctly that you're involved at JDJ somehow), IMHO you're in danger of losing some serious respectability points, as well as treading on thin legal ice. I am not a lawyer by any stretch, but as an author of both books and white papers, I would be furious if this had happened to me, and would be pursuing this with both barrels blazing, so to speak, particularly in light of the entirely inappropriate response above. As an editor as well, I would be furious that an author or authors had tried to sell me material that wasn't theirs to sell.

As to TSS entering the print market, what on earth made you think TSS has any designs in that direction? We're quite happy remaining an online community. Meanwhile, I think, you have other issues to attend.

I find this explanation seriously lacking. To simply claim that "some fairly comment 'security tips' got published as a core article" is to claim that "mistakes were made" and "people were upset". This is a huge embarrassment for any publisher, I understand, but Joseph, those tips read almost word-for-word identical.

I'm not debating that. I'm not even saying "Plagiarism is an unjustified charge." Nor am I unconcerned about the issues - technical and otherwise - brought up. At no point am I dismissing what people are bringing up.

Joseph (if I understand correctly that you're involved at JDJ somehow), IMHO you're in danger of losing some serious respectability points, as well as treading on thin legal ice.

I'm the editor-in-chief of the print edition of JDJ, so yes, I'm "involved" somehow. I'm not sure how my respectability is brought in any further; I'm not dismissing the concerns about the quality of the article, nor am I dismissing charges of plagiarism, but such is not my bailiwick. I'm definitely unhappy, and publicly so, about the whole thing. The article shouldn't have gone to print, for a number of reasons. It did go to print. I publicly discussed it, and continue to do so. Legally, I'm aware of the issues, to be sure. Shaking a big stick in my direction doesn't change that, nor does it change the fact that such charges aren't to be made lightly, dismissed lightly, or even investigated without due care, care which is not my domain. My caution is not to imply that there's nothing wrong here. My caution is indicative of my concern that public cries of plagiarism border on slander for the accused - if it's not plagiarism.

...I am not a lawyer by any stretch, but as an author of both books and white papers, I would be furious if this had happened to me, and would be pursuing this with both barrels blazing, so to speak, particularly in light of the entirely inappropriate response above. As an editor as well, I would be furious that an author or authors had tried to sell me material that wasn't theirs to sell.

Indeed. Which response was inappropriate, Mr. Neward? The one that says "I'd like to be careful here, so that we get it right?"

As to TSS entering the print market, what on earth made you think TSS has any designs in that direction? We're quite happy remaining an online community. Meanwhile, I think, you have other issues to attend.

I wasn't the one to bring that up. Direct any queries there to the appropriate parties.

I would ask that anyone participating on this thread hold off on further comment on the plagiarism discussion for a while; I know that Gary has contacted Joseph and they are discussing it in all detail. Joseph and I have talked a bit over private email, and I'm now convinced that he's taking this charge seriously (which was my principal beef with his response), and is looking to do what's best for all parties concerned, which, he reminded me, includes the authors of the article in the event that it's discovered that no such plagiarism occurred. Kudos to him for trying to steer the line of "innocent until proven guilty" on this topic.

The right thing is trying to be done here, and I'd hate for Joseph to take further flak for commenting on something that he really can't comment on (for a variety of reasons, legal and moral/ethical).

Regarding TSS wanting to enter the print market, Joseph was merely responding to a comment I made in this thread, as people do on discussion boards. Take it easy. It's a discussion board for Christ's sake, not an exam.

As a person who has had to deal with plagiarism of my own articles, I found the similarities between the first part of this article and the guidelines given by the authors of the book Securing Java in chapter 7 section 1 to be eerily close. Fortunately, this book is freely available on the net and I will leave you to make a decisive judgement on whether the first part of this article is plagiarized to a heavy degree or not. (Note that the authors give a link to the book in the list of references. However, that does not allow them to plagiarize its contents.)

All rules, except for rule 6, have been lifted straight out of this book. Further, the article authors have gone ahead and lifted the text describing the rules as well out of this book. Listed below are only some of the sample areas where the plagiarism is seriously obvious.

1. Consider part of rule 3 in the offending article:

"Java's object cloning mechanism can allow an attacker to manufacture new instances of classes that you define, without executing any of the class's constructors. Even if your class is not cloneable, the attacker can define a subclass of your class, make the subclass implement java.lang.Cloneable, then create new instances of your class by copying the memory images of existing objects. By defining the above clone method, you'll prevent such attacks."

and the same rule description in the original book (rule 8)

"Java's object-cloning mechanism can allow an attacker to manufacture new instances of classes you define, without executing any of your constructors. If your class is not cloneable, the attacker can define a subclass of your class, and make the subclass implement java.lang.Cloneable. This allows the attacker to make new instances of your class. The new instances are made by copying the memory images of existing objects; although this is sometimes an acceptable way to make a new object, it often is not."

2. Consider rule 7 in the offending article:

"If a class, method, or variable is not private, hackers could use it as a potential entry point. If there is a good reason why a method, field, or class should not be private, it does not need to be private, but that reason should be clearly documented." and the same rule in the online version of the book (rule 2):

"Every class, method, and variable that is not private provides a potential entry point for an attacker. By default, everything should be private. Make something non-private only if there is a good reason, and document that reason."

3. Finally, consider rule 4 in the offending article:

This rule requires that if you want to prevent access to the internal state of your objects, make your class nonserializable. If you don't, your objects can be serialized into readable byte arrays. As a result, hackers can view the objects' full internal state, including private fields and the internal states of referenced objects.

And the same in the book:Serialization is dangerous because it allows adversaries to get their hands on the internal state of your objects. An adversary can serialize one of your objects into a byte array that can be read. This allows the adversary to inspect the full internal state of your object, including any fields you marked private as well as the internal state of any objects you reference.

I will leave you to compare the rest of the article and the book's contents.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.