The CERT Oracle Secure Coding Standard for Java

R

rCs

The CERT Oracle Secure Coding Standard for Java has been completed and
is now ready for https://www.securecoding.cert.org/c...e+CERT+Oracle+Secure+Coding+Standard+for+Java.

The CERT Oracle Secure Coding Standard for Java provides rules for
secure coding in the Java programming language. The goal of these
rules is to eliminate insecure coding practices that can lead to
exploitable vulnerabilities.

To review, you can create an account on the wiki and then post
comments to any of the pages, or respond directly to me.

Thanks,
rCs
 
J

Jeff Higgins

The CERT Oracle Secure Coding Standard for Java has been completed and
is now ready for https://www.securecoding.cert.org/c...e+CERT+Oracle+Secure+Coding+Standard+for+Java.

The CERT Oracle Secure Coding Standard for Java provides rules for
secure coding in the Java programming language. The goal of these
rules is to eliminate insecure coding practices that can lead to
exploitable vulnerabilities.

To review, you can create an account on the wiki and then post
comments to any of the pages, or respond directly to me.

Thanks,
rCs

Thanks for the link.

Spotted a typo, third paragraph IDS01-J

"Character information in Java 1.6 is based on the Unicode Standard,
version 4.0 [Unicode 2003]. Character information in Java 1.6 is based
on the Unicode Standard, version 6.0.0 [Unicode 2011]."
 
A

Arved Sandstrom

The CERT Oracle Secure Coding Standard for Java has been completed and
is now ready for
https://www.securecoding.cert.org/c...e+CERT+Oracle+Secure+Coding+Standard+for+Java.


The CERT Oracle Secure Coding Standard for Java provides rules for
secure coding in the Java programming language. The goal of these
rules is to eliminate insecure coding practices that can lead to
exploitable vulnerabilities.

To review, you can create an account on the wiki and then post
comments to any of the pages, or respond directly to me.

Thanks,
rCs

Thanks for the link.

Spotted a typo, third paragraph IDS01-J

"Character information in Java 1.6 is based on the Unicode Standard,
version 4.0 [Unicode 2003]. Character information in Java 1.6 is based
on the Unicode Standard, version 6.0.0 [Unicode 2011]."
It's great material. I'm familiar with Robert Seacord's C/C++ security
writing, he knows his stuff. The CERT Oracle Secure Coding Standard for
Java is a good complement to the Secure Coding Guidelines for the Java
Programming Language from Sun/Oracle, and the OWASP Java/Java EE material.

AHS
 
L

Lawrence D'Oliveiro

The CERT Oracle Secure Coding Standard for Java ...

I wonder how many times you can say “The CERT Oracle Secure Coding Standard
for Java†in one posting?
 
L

Lew

I wonder how many times you can say “The CERT Oracle Secure Coding Standard
for Java†in one posting?

There are only practical limits. I'd guess three or four hundred before the
poster loses patience. You just hit Ctrl-A, Ctrl-C, Ctrl-End, Ctrl-V over and
over until bored.

I notice, though, that you quoted two posts to make your point, not one, for a
total of three mentions, Lawrence. That's only an average of 1.5 times per
post, Lawrence. Two of those mentions were from the guy shilling for the
site, Lawrence, and only one from the person to whom you responded, Lawrence.
That doesn't seem excessive, Lawrence. Why did it attract your attention,
Lawrence?
 
N

Nasser M. Abbasi

The CERT Oracle Secure Coding Standard for Java has been completed and
is now ready for https://www.securecoding.cert.org/c...e+CERT+Oracle+Secure+Coding+Standard+for+Java.

The CERT Oracle Secure Coding Standard for Java provides rules for
secure coding in the Java programming language. The goal of these
rules is to eliminate insecure coding practices that can lead to
exploitable vulnerabilities.

To review, you can create an account on the wiki and then post
comments to any of the pages, or respond directly to me.

Thanks,
rCs

I thought Java was already secured? i.e. no buffer overflow
problems like with C, and the sandbox thing for applets and
all of that. I did not know that Java can be not secured before.

But, would it be not better, if the language can be defined
so that these remaining security holes that can make it not
secure be closed at the language definition level, instead of
having set of rules, that one need to print out and hang on
the wall to look at while coding? This way the compiler job
to spot them, not the programmer. Much better.

Just asking, that is all.

--Nasser
 
E

Eric Sosman

I thought Java was already secured? i.e. no buffer overflow
problems like with C, and the sandbox thing for applets and
all of that. I did not know that Java can be not secured before.

Follow the link, read at least the introduction, and improve
your understanding.
But, would it be not better, if the language can be defined
so that these remaining security holes that can make it not
secure be closed at the language definition level, instead of
having set of rules, that one need to print out and hang on
the wall to look at while coding? This way the compiler job
to spot them, not the programmer. Much better.

"Security" is not a property of a language in isolation
(nor of any tool in isolation), but only in the context of
desired and undesired behaviors. The desires are not the
tool's, but the user's. The compiler cannot read your mind,
especially concerning matters you haven't thought about yet.

Power saws these days usually have blade guards and other
such security features to help their operators keep all their
fingers close at, er, hand. But no saw, no matter how safe,
will refuse to cut great gouges in the priceless antique table.
 
D

Daniele Futtorovic

I thought Java was already secured? i.e. no buffer overflow
problems like with C, and the sandbox thing for applets and
all of that. I did not know that Java can be not secured before.

As the tools become more sophisticated, the standards do, too.
 
A

Arved Sandstrom

I thought Java was already secured? i.e. no buffer overflow
problems like with C, and the sandbox thing for applets and
all of that. I did not know that Java can be not secured before.

But, would it be not better, if the language can be defined
so that these remaining security holes that can make it not
secure be closed at the language definition level, instead of
having set of rules, that one need to print out and hang on
the wall to look at while coding? This way the compiler job
to spot them, not the programmer. Much better.

Just asking, that is all.

--Nasser
Java has strong security features, sure. Fairly type-safe, automatic GC,
no direct memory allocation, and secure class-loading/verification to
make sure only legitimate Java bytecode is executed.

If you choose to use a security manager - and for applications (programs
started with "java") it really _is_ a choice - then you get
codebase-level security: this code can operate on files in that
directory, or that code cannot do a specific network operation, that
kind of thing. This is where code signing also comes into play.

If you want to move past a simplistic security model then you need to
implement authentication and authorization. Although Java provides the
hooks for specifying whether or not method A in class B can be invoked
by code from class C in package D, executing as Principal P1, and this
is even simplified with annotations in several environments, the fact is
that you have to do all of the heavy lifting of:

1. Deciding what your Subject, Principals and credentials are;

2. Writing all your Policies (is access to a specific protected resource
allowed to code from a given origin, possible signing, and executing as
a given Subject);

3. Implementing your authentication and authorization: you might do JAAS
fairly directly with an app client or web client (web framework), you
might use something better like Apache Shiro, it's up to you.

Once you've got all of that done - and it's not easy to do correctly -
then the task of locating and plugging (or better yet, not having
created in the first place) all the other application security loopholes
is still present. This other stuff is what those cited references (CERT
Oracle Secure Coding Standard for Java, Secure Coding Guidelines for the
Java Programming Language from Sun/Oracle, and OWASP guidelines) spend
most of their time on. Those guidelines have little to do with platform
security, they have to do with _application_ security.

As an example, why should the language stop you - the coder - from
writing constructors that call overridable methods? Why should the
language enforce best practices around mutable/immutable objects? How
can the language decide which of your methods should have what
visibility? How does Java know that method X is intended only to read
from a given table of a database, and _not_ write to any? How is Java
going to make sure that you've got your concurrency correct? How does
Java control what data you put in your application logs? How will the
language make sure that you're using assertions properly, or avoiding
all possible NPEs?

I recommend that you read (at least scan over) at least one of the
references provided. Just looking at the bullets for the CERT
guidelines, or for the Sun/Oracle guidelines, will give you an idea of
how much stuff is actually covered in _application_ security, and why
JVM security and Java security APIs only take you that first fraction of
the way. Most of the work is, and has to remain, up to you.

It's like this on any platform and with any language. It's easier with
Java in 2011 than it is with a lot of other technologies. But it's still
difficult - which is why most Java applications are insecure.

AHS
 
J

John B. Matthews

Nasser M. Abbasi said:
I thought Java was already secured? i.e. no buffer overflow
problems like with C, and the sandbox thing for applets and
all of that. I did not know that Java can be not secured before.

But, would it be not better, if the language can be defined
so that these remaining security holes that can make it not
secure be closed at the language definition level, instead of
having set of rules, that one need to print out and hang on
the wall to look at while coding? This way the compiler job
to spot them, not the programmer. Much better.

Just asking, that is all.

This related thread

<http://groups.google.com/group/comp.lang.ada/browse_frm/thread/bb14f1c1986544fb/>

adduced many of the same helpful responses seen in this thread itself:

<http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/ed6b7366b0df754a>

One document mentioned there was particularly comprehensive: NASA
Software Safety Guidebook:

<http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf>

FindBugs is especially handy for highlighting potential violations:

<http://findbugs.sourceforge.net/>
 
R

rCs

Spotted a typo, third paragraph IDS01-J

"Character information inJava1.6 is based on the UnicodeStandard,
version 4.0 [Unicode 2003]. Character information inJava1.6 is based
on the UnicodeStandard, version 6.0.0 [Unicode 2011]."

Thanks, got it!

rCs
 
A

Abu Yahya

The document looks really great and helpful.

Just a minor question...does the word "Oracle" in the document title
imply that this is r by Oracle themselves?

For some reason, those words starting with "r" disappeared. I meant
"recommended or ratified by Oracle".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top