Re: > Sandboxed power == More secure???
On 4/26/2013 11:05 PM, markspace wrote:
On 4/26/2013 7:11 PM, Arne Vajh?j wrote:
On 4/25/2013 11:54 AM, markspace wrote:
<http://www.oracle.com/technetwork/java/seccodeguide-139067.html>
...
Oracle should really devote some resources to fixing this. And by
"fixing" I mean obviating every last item in that document.
I don't think that is possible or desirable.
A lot of this has to be done by the developer based
on context.
I see a few things in that document that should be done by the
developer. I see a lot more that really shouldn't be the developers
concern, under any circumstances.
* release resources
* protect against integer overflow
* no sensitive info in exceptions
* no sensitive info in logs
* protect against SQL injection
* protect against XSS
* limit visibility
* validate input
* no sensitive info serialized
* check access
etc.
are all very important items. And pretty close to OWASP.
But doing this is programming.
Java language/Java library/Java VM can do this for programmers.
I'd honestly like to see some discussion about it because I'd like to
propose some fixes to Oracle. Otherwise I think applets are just plain
doomed.
For example, some "context" for applets that I'm concerned about where
Oracle pushes security onto the developer:
1. Mutable statics. This includes private fields, if I read the
document aright.
They note that even if private then there is most likely a method
to change it with.
They are expressing concerns because JavaScript / other applets may
change state of an applet.
2. "Exceptions." WTH?
What about exceptions?
The need to free resources and not reveal sensitive information
is valid for most Java not just applets.
3. Call backs, including applets, which are apparently invoked with full
permissions.
Applets are not invoked with full permissions.
But the text is interesting:
<quote>
Guideline 9-2: Beware of callback methods
Callback methods are generally invoked from the system with full
permissions. It seems reasonable to expect that malicious code needs to
be on the stack in order to perform an operation, but that is not the
case. Malicious code may set up objects that bridge the callback to a
security checked operation. For instance, a file chooser dialog box that
can manipulate the filesystem from user actions, may have events posted
from malicious code. Alternatively, malicious code can disguise a file
chooser as something benign while redirecting user events.
Callbacks are widespread in object-oriented systems. Examples include
the following:
Static initialization is often done with full privileges
Application main method
Applet/Midlet/Servlet lifecycle events
Runnable.run
</quote>
I can't quite see what scenario they are talking about.
Those are all issues, and they need to be addressed in a serious way. Or
Oracle is simply not going to have any presence on the desktop in any
way.
Applets are only one type of desktop app.
Normal Java apps run with full permission anyway.
And neither applets nor Java desktop apps are widely used.
Oracle does not make a cent from applets or Java desktop
apps, so they most likely do not care about usage.
I am assuming that Oracle's only interest in this is to preserve
Java's "good name". Because Oracle is selling billions of
dollars of server side Java stuff. And if everybody get the
impression that Java is "insecure", then it could hurt that
business.
Arne