Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: The CERT Oracle Secure Coding Standard For Java

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

Book Reviews 66

brothke writes "It has been a decade since Oracle started their unbreakable campaign touting the security robustness of their products. Aside from the fact that unbreakable only refers to the enterprise kernel; Oracle still can have significant security flaws. Even though Java supports very strong security controls including JAAS (Java Authentication and Authorization Services), it still requires a significant effort to code Java securely. With that The CERT Oracle Secure Coding Standard for Javais an invaluable guide that provides the reader with the strong coding guidelines and practices in order to reduce coding vulnerabilities that can lead to Java and Oracle exploits." Read on for the rest of Ben's review.The book is from CERT, and like other CERT books, provides both the depth and breadth necessary to gain mastery on the topic.

The first 100 pages of the book are available here. After reading it, you will be likely to want to see the next 650 pages.

This book provides a set of guidelines for secure programming in Java SE 6 and 7 environments. It is primarily targeted at software developers and computer security practitioners. While Java is inherently designed to be relatively secure as compared with other languages, it requires the developer to understand the security controls and language features thoroughly before he can implement them correctly. The book illustrates insecure coding practices and suggests corresponding safe alternatives to enable a developer to have an optimal blueprint.

Software developers are constantly under pressure to accommodate feature requests and have to strike a fine balance between enhancing delivery excellence and releasing a software product in consonance with deadlines. At the same time they routinely tackle technical challenges and often document their experience for the benefit of others. This book is one such effort, in that, several programmers and reviewers have contributed the contents. It encourages a developer to think beyond programming logic and enables him to produce clear, concise, maintainable and secure code – a mandatory requirement for today's dynamic software industry which is plagued by a spectrum of security threats and attrition's.

This book isn't for a Java beginner. The introductory chapter expects an intermediate or seasoned Java professional to identify the gamut of security vulnerabilities that frequently manifest in code and design. The chapter briefly explains injections attacks, unintended information disclosure, denial of service and issues involving concurrency and class loaders. Summary tables have been provided to assist the reader to easily locate representative secure coding rules for each category.

The examples presented primarily encompass the lang and util libraries of Java SE and also cover collections, concurrency, logging, management, reflection, regex, zip, I/O, JMX, JNI, math, serialization and JAXP libraries. No particular Java platform or technology has been favored; the set of rules is generic and independent of whether a mobile, enterprise, desktop or web application is being developed.

Notably, the layout enables the practitioner to pick up any chapter or rule at random without requiring him to read the preceding pages. Each rule has a short description of a unique problem and one or more non-compliant and compliant code examples. Risk assessment and references to other coding standards along with bibliography are also provided.

Unfortunately, the suggested tips for automatic detection of described problems aren't very practical because no automated bug detection tools have been vetted. Some rules also have a related vulnerabilities section that preys on weaknesses in commonplace software in context of the described problem.

Chapter 2 focuses on input validation and data sanitization. It highlights attacks such as SQL, XML, and OS injection and XML External Entity (XXE) and suggests corresponding mitigation techniques. It mentions but doesn't elaborate on web-based attacks such as cross-site scripting and CSRF, to avoid being too domain specific. The chapter advises developers to normalize strings, canonicalize and validate path names, refrain from logging unsanitized input, use appropriate internationalization and globalization APIs, avoid string encoding misgivings and other issues.

Chapters 3, 4 and 5 deal with declarations and class initialization, expressions, and numeric operations respectively. Dangers of auto-boxing, side-effects in assertions, integer overflow, and vagaries of floating point arithmetic are discussed at length.

The examples are short, to the point and intellectually challenging for the advanced reader. For example, one rule – don't use denormalized numbers dissects a vulnerability in Java 1.6 and earlier that allows an attacker to perform a denial of service attack by sending a crafted input to the JVM.

The book devotes a chapter to object-oriented programming and stresses on limiting extensibility of classes, encapsulating data, ensuring that code refactoring doesn't result in broken class hierarchies, using generics for fun and profit and so on.

Another chapter discusses Java methods, for example, one rule suggests that subclasses mustn't increase the accessibility of an overridden method. There is some useful information about using methods of Object class properly. This information is standard advice that can also be found in other books. This book offers all that and more. For example, one rule documents a convincing and exhaustive list of reasons why you shouldn't use finalizers.

The book also highlights misconstrued exception handling practices through examples akin to the shortcuts programmers invent, to save themselves from the trouble of having to handle exceptions. It explains why doing that can be insidious. Information disclosure arising from ill-conceived exception handling strategies is also discussed. Some may disagree with the advice on the pretext that exception handling when done the right way leads to unreadable code, however, the features presented from Java 7 convincingly offer a middle path. Further, when compliance with a certain rule is believed to be challenging and costly, the standard allows documented deviations and even lists valid exceptions for each rule.

Chapters 9, 10, 11, 12 and 13 are reserved for concurrency related issues. There are more than 30 rules in these chapters; the set could qualify as a handbook of concurrency issues and solutions. At a high level, the chapters cover visibility and atomicity, locking, thread class APIs, thread pools and thread safety in multi-threaded Java programs. The chapters don't assume that the reader has any familiarity with multi-threaded programming.

The next few chapters highlight input-output (I/O) risks such as working with shared directories, using files securely, closing resource handles properly, serialization and more. The book doesn't assume that the reader has a sophisticated background in serialization and builds from the basics. It cites examples of vulnerabilities that necessitate understanding the role of serialization.

A chapter on platform security follows, and is meant for advanced Java users. This chapter leads to another on runtime environment that cautions against signing code, granting permissions frivolously and permitting insecure deployment configurations. The final chapter captures miscellaneous rules that forbid hardcoding sensitive information, leaking memory, generating weak random numbers and writing insecure singletons among other topics.

Many other leading security standards delineate high-level measures that must be taken to ensure compliance but most fall short of prescribing the exact recipe to get there. This book fills that gap by approaching security from the ground-zero level upwards. However, it doesn't clearly specify to what extent the rules will help organizations meet the compliance goals proposed by other security standards. All the same, the eighteen crisp chapters of this book undeniably have the potential to help the software developer win the battle against software insecurity on his own terms.

For those using Java on Oracle and hoping to build secure applications, The CERT Oracle Secure Coding Standard for Javais a very useful resource that no programmer should be without.

Ben Rothkeis the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase The CERT Oracle Secure Coding Standard for Java from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

Keepin' it real (-1)

Anonymous Coward | more than 2 years ago | (#38220626)

First post for Jesus

JC in the hizzy

Re:Keepin' it real (1)

MikeKWarren (2467784) | more than 2 years ago | (#38220676)

how come no post for Moses?

Re:Keepin' it real (1)

secretsquirel (805445) | more than 2 years ago | (#38220778)

he prob wouldn't like it, too humble

Re:Keepin' it real (1)

MikeKWarren (2467784) | more than 2 years ago | (#38232456)

very cute....Moses was the most humble person...

Another 10/10 review. (-1)

Anonymous Coward | more than 2 years ago | (#38220638)

Durr. Next!

Re:Another 10/10 review. (0)

Anonymous Coward | more than 2 years ago | (#38220758)

Not only that, it's apparently published by "ddison-Wesley Profession" and the link to "CERT books" takes me to some rambling blog bullshit instead of a list of CERT books, in case I was interested in secure coding standards for C or PHP instead of Java.

Re:Another 10/10 review. (0)

Anonymous Coward | more than 2 years ago | (#38221108)

>>>>Not only that, it's apparently published by "ddison-Wesley Profession"

Oh,,,,they left out the A!

>>>and the link to "CERT books" takes me to some rambling blog bullshit instead of a list of CERT books

the language is 'and like other CERT books', which links to a CERT book. I dont think he meant that it was the actual list of all books CERT.

Re:Another 10/10 review. (0)

Anonymous Coward | more than 2 years ago | (#38222076)

Oh,,,,they left out the A!

...and the 'al' on the end of 'Professional'.

Re:Another 10/10 review. (1)

MikeKWarren (2467784) | more than 2 years ago | (#38225780)

looks like that mistake was korrected :)

Ruby on Rails can't compete wtih this. (-1, Offtopic)

Anonymous Coward | more than 2 years ago | (#38220640)

Java provides a full enterprise stack. Ruby on Rails just can't compete with Java, as much as the Rubyists claim it can. This book just goes to show how far behind the game Ruby on Rails is compared to Java.

I'm bitter about this because I just had to spend the past day in meetings shooting down every idea put forth by some of these Rubyists. For crying out loud, they didn't even know what LDAP is! Near the end of the day we found out that they didn't even have any college or university credentials of any sort. It was at that point that three of us just walked right the fuck out of there. We have real work to do. We don't have time for this Ruby on Rails bullshit.

Until the Ruby on Rails community can get its shit together, they just can't compete in the enterprise space. Their technologies and techniques will either have to mature, or they'll need to fuck off and stick to creating blog and forum software.

Re:Ruby on Rails can't compete wtih this. (1)

Anonymous Coward | more than 2 years ago | (#38220958)

When you're a hipster Rudy coder being University or College educated is counter productive and eats up time shopping for skinny jeans.

Java developers are assholes (-1)

Anonymous Coward | more than 2 years ago | (#38221386)

I too had just similar experience with bunch of Java 'developers'.

  They did not know that data belongs to DBMS. They did not know that applications come and go, but data remains. Heh, they even had problems with foreign keys constraints and they had problems with indexes. So that when the performance is hit, they can always blame the database.

They proposed using Hibernate for database independence. When asked when was the last time any of their project changed backend database, they had no answer to that. These are the scumbags bringing down the whole app dev industry with their nosql bullshit - because of their inability to understand what data is, what data integrity is and that all their tiers are just that - tiers to bring data into the DBMS and then reporting out from it.

PS. See - everybody can have offtopic rants. Now let go of your elitist java bullshit and get on with the program.

Re:Java developers are assholes (0)

Anonymous Coward | more than 2 years ago | (#38222020)

It's a pity your tiny hipster brain couldn't scale.

Re:Java developers are assholes (0)

Anonymous Coward | more than 2 years ago | (#38257192)

Dont feed the trolls! That is all his comment was. stop da feeding.

Re:Java developers are assholes (1)

MikeKWarren (2467784) | more than 2 years ago | (#38232262)

I just love these generalities..........

Re:Ruby on Rails can't compete wtih this. (1)

Anonymous Coward | more than 2 years ago | (#38221476)

I agree. RoR is great, but Java is 10x more mature, more stable, and ultimately, much more secure.

Perhaps in 10 years Ruby will be there...but not now.

Yes it can (0)

Anonymous Coward | more than 2 years ago | (#38223198)

Depending on the size of your team, RoR can be much more secure than Java.

(if you can't imagine, here is a hint: 1 Developer, handling about 20.000 LoC in RoR or 100.000 LoC in Java to do the same .. maybe the Java Compiler finds 3 times more bugs in advance, this still leaves 50% more bugs in the java-software as it took 5 times more code.)

(2nd Hint: you want do buy a milk, just use 'plain english': 'Hello, please give me that milk over there'. In Java you could maybe write a software to send an electronic report somewhere to get you milk some other day .. and then your milk is probably already bad and poisones .. so you still think your poisones java-ordered milk is more secure than your 'plain english ordered one? well, your choice ;-)

Re:Yes it can (1)

MikeKWarren (2467784) | more than 2 years ago | (#38232506)

Dont really get your explanation...u got some empirical data to back it up?

Re:Ruby on Rails can't compete wtih this. (2)

ajo_arctus (1215290) | more than 2 years ago | (#38224516)

Ruby on Rails just can't compete with Java, as much as the Rubyists claim it can

Wait, what Rubyists are claiming that?

I'm a Ruby programmer. I'm also a Java programmer and a .NET programmer (and quite a few others besides) so I have a broard perspective. I follow most of the Ruby movers-and-shakers on blogs and Twitter, and I don't think I've ever heard that claim. If anything, Rubyists look to Java as the natural step up from Ruby to meet enterprise needs -- even more so now JRuby is one of the most stable and usable Ruby implementations out there. Twitter built their platform on Ruby and then moved pieces to Java as needed. I don't think their approach is even remotely unique -- I've certainly done the same thing myself.

I think you're repeating sweeping generalisations out of your own (unfounded and biased) opinion and getting it totally wrong.

Re:Ruby on Rails can't compete wtih this. (1)

MikeKWarren (2467784) | more than 2 years ago | (#38226376)

there is no comparison bet. the 2...Java vs. RoR is major vs. minor leagues.

Where's muh Drupal reviews? (-1)

Anonymous Coward | more than 2 years ago | (#38220682)

Where's muh reviews for Packt Publishing books on 3-year-old versions of Drupal? Fuck this Java shit..

Re:Where's muh Drupal reviews? (1)

MikeKWarren (2467784) | more than 2 years ago | (#38220708)

wat be yer point?

Pretty decent general coding practices (2)

elh_inny (557966) | more than 2 years ago | (#38220698)

It seem they provide a decent set of good practices that should result in more manageable code overall, not just from security point of view, but one that is easier to maintain and better suitet to modern, multi-threaded, shared, virtualised environments where code is usually run...

Re:Pretty decent general coding practices (3, Insightful)

jd (1658) | more than 2 years ago | (#38221020)

Good programming practices are essential in all aspects of programming, code management and indeed software design.

There is, of course, a balance point - the better the programming practice, the more effective the testing and the more confident you can be in the final outcome, but it follows the usual law of diminishing returns once you pass a certain point. You can prove certain classes of program correct within finite resources (Turing's Halting Theorum only shows that you cannot prove ALL programs correct) where the range of classes increases linearly when the resources increase exponentially.

In other words, "good general programming practices" want to be efficient enough to be usable for the widest possible number of cases AND allow the best possible testing for those cases even if that means sacrificing certainty.

Really, what is wanted is a set of books, each for a different required confidence level. This would make an excellent book #1 in the set. Book #2 onwards would need to add to the book before, explaining where a certain methodology simply won't work at the more stringent level and what you replace it with. For example, their compliant solution on page 25 for doPrivilegedAction() is good for a basic level of confidence but has flaws. There's magic numbers (an 8 for the maximum length of a username), the program flow isn't great (check for a maximum length doesn't actually trip an exception), some parameters aren't sanity-checked (the password is passed straight to the hash function without knowing if it meets the size requirements for the function or if there's anything in the string that might break things). It's perfectly good for a basic level of good practice, but I wouldn't consider it adequate for more advanced levels.

(Having everything in one single book and coding to an insanely high standard is why the DoD's efforts for higher quality code ultimately failed. It had nothing to do the limits of what people can do, it had everything to do with what people have time to do. You need a good baseline and build from it.)

The thing that concerns me is that Oracle will probably consider this sufficient for everyone, which it isn't. The standards are not even up to the quality needed by e-Commerce and should not be used directly from this book for that purpose. This is a foundation layer, it isn't the entire edifice.

Re:Pretty decent general coding practices (4, Informative)

Arslan ibn Da'ud (636514) | more than 2 years ago | (#38221618)

Disclaimer: I'm one of the authors.

Really, what is wanted is a set of books, each for a different required confidence level. This would make an excellent book #1 in the set. Book #2 onwards would need to add to the book before, explaining where a certain methodology simply won't work at the more stringent level and what you replace it with. For example, their compliant solution on page 25 for doPrivilegedAction() is good for a basic level of confidence but has flaws. There's magic numbers (an 8 for the maximum length of a username), the program flow isn't great (check for a maximum length doesn't actually trip an exception), some parameters aren't sanity-checked (the password is passed straight to the hash function without knowing if it meets the size requirements for the function or if there's anything in the string that might break things). It's perfectly good for a basic level of good practice, but I wouldn't consider it adequate for more advanced levels.

I'm not sure what you are referring to on page 25, there is no doPrivileged() block there. But go ahead & contact me with specific criticisms or comments on the rules.

Some of the problems you cite arise from the main purpose of the code examples, which is to be illustrative, rather than to be functional. For example, I'll agree that magic numbers in code are generally a bad idea, and should be replaced with constants. In fact, we considered adding a rule about this to the book, and nixed it because that is purely a maintainability issue, with no direct ramifications to security. (That is, you'd have to work hard to contrive an example where failing to use magic numbers makes your program vulnerable rather than just buggy.)

Using 'magic numbers' also makes the code bigger, and a little harder to read. For code whose purpose is to work properly, this extra code size is no big deal, but when the code's purpose is to serve as an illustration in a book, this bloat is more problematic. If the code has to appear on a PowerPoint slide, this bloat can be critical.

(Having everything in one single book and coding to an insanely high standard is why the DoD's efforts for higher quality code ultimately failed. It had nothing to do the limits of what people can do, it had everything to do with what people have time to do. You need a good baseline and build from it.) The thing that concerns me is that Oracle will probably consider this sufficient for everyone, which it isn't. The standards are not even up to the quality needed by e-Commerce and should not be used directly from this book for that purpose. This is a foundation layer, it isn't the entire edifice.

I suspect the ediface you are imagining is a tower of babel...it will never be complete. True security is an impossible dream, that we can asymptotically approach yet never attain. In this book, we tried to focus on the insecure coding practices being made today; we ignored 'theoretical' insecure coding practices that aren't being widely done today. Mainly to keep the project a manageable size :)

Re:Pretty decent general coding practices (0)

Anonymous Coward | more than 2 years ago | (#38222966)

Really one of the authors??

Accd. to http://www.amazon.com/Oracle-Secure-Standard-Software-Engineering/dp/0321803957/ref=ntt_at_ep_dpt_1, the authors are:
Fred Long
Dhruv Mohindra
Robert C. Seacord
Dean F. Sutherland
David Svoboda

Re:Pretty decent general coding practices (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38223618)

That's David Svoboda you insensitive clod.

Re:Pretty decent general coding practices (0)

Anonymous Coward | more than 2 years ago | (#38251868)

Page 33 reads
reader.setErrorHandler(defaultHandler);
and it should read
reader.setContentHandler(defaultHandler);

Re:Pretty decent general coding practices (1)

Arslan ibn Da'ud (636514) | more than 2 years ago | (#38266006)

Thanks for this notice. I've added it to our 'Errata', so it should be fixed in the next reprinting.

It is more a style issue rather than a correctness issue (the code in the book *is* correct), but we should also be promiting good style too :)

Re:Pretty decent general coding practices (1)

dvdwholesale3 (2432850) | more than 2 years ago | (#38322152)

P90x is an extremely intense program.Sheer will and determination may get you to the finish line,but to achieve the best results,you’ve got to have the proper quality and quantity of nutrition.We make these supplements optional,so you have a choice.But know that P90x supplements were designed for this program and will supply your body with the necessary nutrients to give you added strength energy,and stamina for each workout. As you may notice from the math on the following pages,P90x is not bulit around adaily “calorie deficit” for weight loss like the general Beachbody plans found in Power 90,Kathy Smits’s Project :You!Type 2,and Slimin 6.It’s important that you understand why ,so you have the right training mentality with this program ,with the right expectations. http://www.dvd4wholesale.com/exercise-fitness-dvds/34-p90x-textrme-home-fitness-13-discs-set-wholesale.html [dvd4wholesale.com]

Re:Pretty decent general coding practices (0)

Anonymous Coward | more than 2 years ago | (#38257260)

Thank you for your good observation. this is perhaps just 2 of the 60 comments that have anything to do w/ the review, the topic or the issue. and not silly grammar issues or politics....

Decent set of general coding practices (0)

elh_inny (557966) | more than 2 years ago | (#38220742)

It seems they provide a decent set of good practices that should result in more manageable code overall, not just from security point of view, but one that is easier to maintain and better suitet to modern, multi-threaded, shared, virtualised environments where code is usually run...

Really decent set of general coding practices (0)

Anonymous Coward | more than 2 years ago | (#38220762)

It seems they provided a decent set of good practices that should result in more manageable code overall, not just from security point of view, but one that is easier to maintain and better suitet to modern, multi-threaded, shared, virtualised environments where code is usually run...

750 pages? (1, Insightful)

Vellmont (569020) | more than 2 years ago | (#38220914)

I hate books that are this long on a single subject. Most of the time I find books over 400 pages to be mostly filler material which I wind up having to wade through to get to the real content.

Technical books are ordinarily very dry and tedious, and reading them is often a chore. So as to avoid prying my eyes off each page with a spatula, I find it especially important for authors of technical books to put up an effort to be brief rather than cover every single conceivable aspect of something.

Re:750 pages? (1)

Anonymous Coward | more than 2 years ago | (#38221168)

who could write a book on Oracle secure coding in less than at least 500 pages?

there is a lot to it.

also realize, that this book seems to have a lot, and i mean a lot of coding examples.
that is good, but adds to the page count.

Re:750 pages? (2)

Arslan ibn Da'ud (636514) | more than 2 years ago | (#38221708)

Let me explain...no there is too much. Let me sum up.

I've read 1000-page technical books that had no filler (at least none that I could find). They just had a LOT of ground to cover. Sigh. How do you distinguish the books with mostly filler from the books that aren't? You gotta slog through the whole thing. Or you gotta trust that that review you're reading was done by someone who slogged through the whole thing.

Sounds like you want more of a tutorial in the style of K\&R, rather than a reference book like this.

Re:750 pages? (1)

Vellmont (569020) | more than 2 years ago | (#38229170)


Sounds like you want more of a tutorial in the style of K\&R, rather than a reference book like this.

For the most part, yes. The hard part about learning anything new is the general concepts, not the excruciating detail. I find too often that authors (and instructors) are far too convinced they have to cover every aspect of something, as if the learning stops when you finish the book.

Don't you just love Java (-1, Troll)

Dark$ide (732508) | more than 2 years ago | (#38220964)

Write once

Debug everywhere.

Re:Don't you just love Java (1, Troll)

Arslan ibn Da'ud (636514) | more than 2 years ago | (#38221728)

I think that needs to be updated:

Pwn once.
Patch everywhere.

Re:Don't you just love .NET (-1)

Anonymous Coward | more than 2 years ago | (#38222352)

Write Once
Crash on Winblows

I know why it has so many pages (5, Funny)

stenno (2520180) | more than 2 years ago | (#38221004)

Obligatory bash quote: http://bash.org/?946461 [bash.org]

High-Assurance Design (3, Informative)

cjonslashdot (904508) | more than 2 years ago | (#38221280)

Those who are interested in this book might also be interested in High-Assurance Design (660 pages, Addison-Wesley). (See http://assuredbydesign.com/haa/ [assuredbydesign.com] ) It has a foreword by Peter Neumann, and contains much of the same material as the book being reviewed, as well as many secure design patterns, social engineering patterns, and attack patterns. The book also covers the topic of software reliability - not just security. Disclosure: I wrote High-Assurance Design, as well as Prentice Hall and Sun Microsystem's book Advanced Java 2 Development For Enterprise Applications.

Re:High-Assurance Design (0)

Anonymous Coward | more than 2 years ago | (#38221300)

I second that...Berg is great

FUCKING ENGLISH, DO YOU SPEAK IT (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38221360)

a fine balance between enhancing delivery excellence and releasing a software product in consonance with deadlines.

Can I get this translated into English, please? I try to avoid parsing marketroid and/or manager babble. ;)

Re:FUCKING ENGLISH, DO YOU SPEAK IT (1)

colinrichardday (768814) | more than 2 years ago | (#38221678)

Can I get this translated into English, please?

Sorry, no, there is no English translation.

Re:FUCKING ENGLISH, DO YOU SPEAK IT (4, Insightful)

Arslan ibn Da'ud (636514) | more than 2 years ago | (#38221848)

a fine balance between enhancing delivery excellence and releasing a software product in consonance with deadlines.

Can I get this translated into English, please? I try to avoid parsing marketroid and/or manager babble. ;)

No, but here is a translation you'll understand:

Project code = getProject();
int softwareQuality = QA.getQuality( code);
Date deadline = Boss.getDeadline();
Date completionDate = estimateRemainingWork( Project.codingQuality);
while (completionDate > deadline) {
    Project.codingQuality--;
    completionDate = estimateRemainingWork( Project.codingQuality);
}

Re:FUCKING ENGLISH, DO YOU SPEAK IT (1)

Migala77 (1179151) | more than 2 years ago | (#38228546)

I tried running this, and it seems to just increase the load and never actually finish!

(not until something gets killed anyway)

Re:FUCKING ENGLISH, DO YOU SPEAK IT (2)

luis_a_espinal (1810296) | more than 2 years ago | (#38222602)

a fine balance between enhancing delivery excellence and releasing a software product in consonance with deadlines.

Can I get this translated into English, please? I try to avoid parsing marketroid and/or manager babble. ;)

Deliver on time shit that works with quality, don't sacrifice quality too much just to meet deadlines, and don't blow deadlines too much just to make shit perfectly pretty.

Re:FUCKING ENGLISH, DO YOU SPEAK IT (0)

Anonymous Coward | more than 2 years ago | (#38238892)

dont be so mean mr coward......

Re:FUCKING ENGLISH, DO YOU SPEAK IT (0)

Anonymous Coward | more than 2 years ago | (#38239136)

After thinking about this, this was a mean comment.

but then again, welcome to /.

But Java is secure! (1)

gillbates (106458) | more than 2 years ago | (#38222104)

Doesn't anyone remember that when Java first came out that it was marketed as a secure alternative to C and C++? Proponents claimed that Java got the security model right, and that we could all just get down to solving the problems at hand, rather than having to worry about writing insecure code.

I guess it just goes to show that you can write security vulnerabilities in any language.

The security problem isn't in the language, but the programmer. Any programming language requires diligence wrt to security, and Java is no different. Those who couldn't write secure code in C won't be writing secure code in Java, either.

Now this is not to say that Java is inherently insecure, but that security is not so much an attribute of the language, but the programmer. One of the most secure operating systems on the planet is written in C, not Java.

There are many reasons to use Java, but as this book clearly demonstrates, security is not one of them. The notion that a language automatically provides security is flawed, at best. The best a language can do is provide a mental model which encourages secure coding. The rest is on the programmer.

Re:But Java is secure! (5, Insightful)

Arslan ibn Da'ud (636514) | more than 2 years ago | (#38222384)

Doesn't anyone remember that when Java first came out that it was marketed as a secure alternative to C and C++? Proponents claimed that Java got the security model right, and that we could all just get down to solving the problems at hand, rather than having to worry about writing insecure code.

Agreed. Java did get some things right. When was the last time someone took advantage of a buffer overflow in a Java program? (I'm talking about the Java language here, not about vulnerabilities in particular implementations of Java.) The fact that it garbage-collects memory for you is not only convenient, but closes off a whole class of vulerabilities like double-free, that still plague C/C++ programmers.

On top of that, Java provides a standard API for concurrency...standard C and C++ didn't provide any threading model until this year.

And Java provides a framework allowing a program to run hostile code and still maintain control. C has no such capability; if your C program runs hostile code, game over, you're pwned. So I'd say Java did solve some of the biggest problems affecting C...buffer overflows and memory-allocation errors. I'd say that makes Java more secure than C. The problems outlined in the book can mostly be applied to C as well, though you'll have to go outside the standard to do them (eg for multithreaded code).

There are many reasons to use Java, but as this book clearly demonstrates, security is not one of them. The notion that a language automatically provides security is flawed, at best. The best a language can do is provide a mental model which encourages secure coding. The rest is on the programmer.

I'd say that no language provides security, as perfect security is an impossible dream...we can strive for it, and approach it, but never quite reach it. So I'd rather say that Java provides more security than C.

Re:But Java is secure! (1)

zaphirplane (1457931) | more than 2 years ago | (#38225294)

The fact that it garbage-collects memory for you is not only convenient, but closes off a whole class of vulerabilities like double-free, that still plague C/C++ programmers.

out of interest why does free not null out the pointer

Re:But Java is secure! (1)

Arslan ibn Da'ud (636514) | more than 2 years ago | (#38225564)

out of interest why does free not null out the pointer

Well, C's free() is a library function, so it only gets a pointed-to value, not the actual pointer itself. But if free() could magically null the pointer, would that solve your problem? Your program could have other copies of the pointer that free() wouldn't know about; those would still be dangerous.

Java's GC fixes this problem by freeing memory only when it knows no object references point to it.

buffer overflows (0)

Anonymous Coward | more than 2 years ago | (#38225720)

Java is but one of many languages which prevent buffer overflows by handling memory allocation internally.

Re:But Java is secure! (1)

MikeKWarren (2467784) | more than 2 years ago | (#38230232)

Yours is the best comment on this entire thread...very thought provoking...thank you.

How is the readability? (1)

phantomfive (622387) | more than 2 years ago | (#38223390)

Is the bookreadable? Or am I going to be glad I read it, but miserable the whole time I'm reading it?

Re:How is the readability? (1)

MikeKWarren (2467784) | more than 2 years ago | (#38225522)

If u like reading code, yes.

Get real (0)

Anonymous Coward | more than 2 years ago | (#38224218)

rewrite the book as a specification that can be referred to in a contract.

Re:Get real (1)

MikeKWarren (2467784) | more than 2 years ago | (#38225472)

I like that idea :)

But... Java is the biggest hole ever!? (2, Informative)

Anonymous Coward | more than 2 years ago | (#38225692)

It's kinda twisted ain't it? It's now official: Java was the single biggest attack vector in 2010 and it's so far ahead of Flash (and JavaScript) that it's going the "win" the award for being the biggest desktop security hole in 2011 too.

And I'm a Java developer (and I did patch in february the remote DoS "2.2250738585072012e-308" bug). So don't see this as "Java bashing".

Honestly it's sad for a VM that doesn't allow buffer overflow/overrun to see all the myriad other holes that it's suffering from. It's a joke. A very, very, sad joke.

And one can't help pitty all the users who do not need Java and who caught malware due to Java holes in 2010/2011.

So "Oracle best security practices for Java", sure... But what's the point when the VM itself is full of holes?

Re:But... Java is the biggest hole ever!? (1)

MikeKWarren (2467784) | more than 2 years ago | (#38225890)

That is due to the fact that Java is the most all-encompassing programming language. In the same sense that Windows is the most pervasive operating systems. The attackers shoot for the bugs where they have the most bang for the buck.

Re:But... Java is the biggest hole ever!? (-1)

Anonymous Coward | more than 2 years ago | (#38226906)

That is due to the fact that Java is the most all-encompassing programming language. In the same sense that Windows is the most pervasive operating systems. The attackers shoot for the bugs where they have the most bang for the buck.

Please do not feed the "Anonymous Coward" trolls.....

Re:But... Java is the biggest hole ever!? (1)

MikeKWarren (2467784) | more than 2 years ago | (#38227118)

From one Anonymous Coward to another...is there anything in that comment that is at all incorrect?

Re:But... Java is the biggest hole ever!? (1)

Anonymous Coward | more than 2 years ago | (#38231380)

[citation for you claim?]

There are VERY VERY VERY few VM security holes in the Sun (now Oracle) VM. Like, on the order of 10 since Sun started writing Hotspot, over a decade and a half ago. There have a been a few more JDK (i.e. library) security holes, but even there, not that many (maybe 20 or so). There have been plenty of bugs, of course (though, given the size of the codebase, a rather low number), but actual Security issues have been extraordinarily rare.

FYI - 2.2250738585072012e-308 wasn't a VM problem, it was a JDK (library and javac) issue. It's also not really a security issue, but a bug. Yes, it could be used to hang a system, but that's not immediately a reason to be categorized as a security bug. Any more than the ability to fork unlimited processes from a UNIX shell is a security problem.

As usual, you confuse bugs with security issues, and also mistake issues with Java tools as being with the JDK/VM itself.

Re:But... Java is the biggest hole ever!? (1)

MikeKWarren (2467784) | more than 2 years ago | (#38231494)

sorry, whose claim did you want info for?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?