The CERT Oracle Secure Coding Standard for Java

Discussion in 'Java' started by rCs, May 27, 2011.

  1. rCs

    rCs Guest

    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
     
    rCs, May 27, 2011
    #1
    1. Advertising

  2. rCs

    Jeff Higgins Guest

    On 05/27/2011 01:44 PM, rCs wrote:
    > 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]."
     
    Jeff Higgins, May 27, 2011
    #2
    1. Advertising

  3. On 11-05-27 07:43 PM, Jeff Higgins wrote:
    > On 05/27/2011 01:44 PM, rCs wrote:
    >> 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
     
    Arved Sandstrom, May 27, 2011
    #3
  4. In message <5UVDp.23993$>, Arved Sandstrom wrote:

    > On 05/27/2011 01:44 PM, rCs wrote:
    >
    >> The CERT Oracle Secure Coding Standard for Java ...
    >>
    >> The CERT Oracle Secure Coding Standard for Java ...

    >
    > 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?
     
    Lawrence D'Oliveiro, May 28, 2011
    #4
  5. rCs

    Lew Guest

    On 05/28/2011 12:31 AM, Lawrence D'Oliveiro wrote:
    > In message<5UVDp.23993$>, Arved Sandstrom wrote:
    >
    >> On 05/27/2011 01:44 PM, rCs wrote:
    >>
    >>> The CERT Oracle Secure Coding Standard for Java ...
    >>>
    >>> The CERT Oracle Secure Coding Standard for Java ...

    >>
    >> 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?


    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?

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 28, 2011
    #5
  6. On 5/27/2011 10:44 AM, rCs wrote:
    > 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
     
    Nasser M. Abbasi, May 28, 2011
    #6
  7. rCs

    Eric Sosman Guest

    On 5/28/2011 3:42 AM, Nasser M. Abbasi wrote:
    > On 5/27/2011 10:44 AM, rCs wrote:
    >> 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.


    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.

    --
    Eric Sosman
    d
     
    Eric Sosman, May 28, 2011
    #7
  8. On 28/05/2011 09:42, Nasser M. Abbasi allegedly wrote:
    > On 5/27/2011 10:44 AM, rCs wrote:
    >> 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.

    >
    > 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.

    --
    DF.
    Determinism trumps correctness.
     
    Daniele Futtorovic, May 28, 2011
    #8
  9. On 11-05-28 04:42 AM, Nasser M. Abbasi wrote:
    > On 5/27/2011 10:44 AM, rCs wrote:
    >> 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
    >

    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
     
    Arved Sandstrom, May 28, 2011
    #9
  10. In article <irq910$vd8$>,
    "Nasser M. Abbasi" <> wrote:

    > On 5/27/2011 10:44 AM, rCs wrote:
    > > The CERT Oracle Secure Coding Standard for Java has been completed and
    > > is now ready for
    > > https://www.securecoding.cert.org/confluence/display/java/The CERT Oracle Se
    > > cure+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.

    >
    > 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/>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
     
    John B. Matthews, May 29, 2011
    #10
  11. rCs

    rCs Guest


    > 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
     
    rCs, Jun 2, 2011
    #11
  12. rCs

    Abu Yahya Guest

    On 5/27/2011 11:14 PM, rCs wrote:
    > 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
    ><snip>


    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?

    Thanks!
     
    Abu Yahya, Jun 8, 2011
    #12
  13. rCs

    Abu Yahya Guest

    On 6/8/2011 8:52 PM, Abu Yahya wrote:
    > On 5/27/2011 11:14 PM, rCs wrote:
    >> 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
    >> <snip>

    >
    > 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".

    >
    > Thanks!
    >
     
    Abu Yahya, Jun 8, 2011
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Seacord

    CERT C Programming Language Secure Coding Standard

    Robert Seacord, Aug 31, 2006, in forum: C Programming
    Replies:
    7
    Views:
    353
    Bill Pursell
    Sep 18, 2006
  2. Robert Seacord

    CERT C Programming Language Secure Coding Standard

    Robert Seacord, Jul 31, 2007, in forum: C Programming
    Replies:
    16
    Views:
    573
    Eric Sosman
    Aug 3, 2007
  3. rCs
    Replies:
    0
    Views:
    329
  4. Robert Seacord
    Replies:
    118
    Views:
    2,729
    Douglas A. Gwyn
    Apr 22, 2008
  5. David Chan via .NET 247
    Replies:
    1
    Views:
    368
    Dominick Baier [DevelopMentor]
    Jun 2, 2005
Loading...

Share This Page