Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #4685

Re: The CERT Oracle Secure Coding Standard for Java

Show all headers | View raw

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/confluence/display/java/The+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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

The CERT Oracle Secure Coding Standard for Java rCs <rcs@sei.cmu.edu> - 2011-05-27 10:44 -0700
  Re: The CERT Oracle Secure Coding Standard for Java Jeff Higgins <jeff@invalid.invalid> - 2011-05-27 18:43 -0400
    Re: The CERT Oracle Secure Coding Standard for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-27 19:49 -0300
      Re: The CERT Oracle Secure Coding Standard for Java Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-28 16:31 +1200
        Re: The CERT Oracle Secure Coding Standard for Java Lew <noone@lewscanon.com> - 2011-05-28 00:45 -0400
    Re: The CERT Oracle Secure Coding Standard for Java rCs <rcs@sei.cmu.edu> - 2011-06-02 06:14 -0700
  Re: The CERT Oracle Secure Coding Standard for Java "Nasser M. Abbasi" <nma@12000.org> - 2011-05-28 00:42 -0700
    Re: The CERT Oracle Secure Coding Standard for Java Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-28 09:07 -0400
    Re: The CERT Oracle Secure Coding Standard for Java Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-28 15:10 +0200
    Re: The CERT Oracle Secure Coding Standard for Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-28 10:35 -0300
    Re: The CERT Oracle Secure Coding Standard for Java "John B. Matthews" <nospam@nospam.invalid> - 2011-05-29 16:17 -0400
  Re: The CERT Oracle Secure Coding Standard for Java Abu Yahya <abu_yahya@invalid.com> - 2011-06-08 20:52 +0530
    Re: The CERT Oracle Secure Coding Standard for Java Abu Yahya <abu_yahya@invalid.com> - 2011-06-08 20:55 +0530

csiph-web