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