Applets security and HTMLets

[Stefan Ram]

With all the continuous security leak reports about Java in
the press, if I was Oracle, I would try to hire those
security consultants who have found security issues in Java
recently and set up a special and independent department of
maybe 7 - 14 employees whose sole purpose is to find
security holes in Java five days a week (a bonus is paid for
each hole found). Of course, /we/ know that the security
problems only relate to a specific Java runtime /in the
browser/ and that any exe file can do at least as much harm
as a Java applet, but the general audience and some executives
might get the impression that Java was »not secure«.

If, maybe 2 or 3 years later, Java is found to be quite
secure in the browser it might even get a new boost there,
when people say, »Well, JavaScript is nice, but Java s so
much more secure.« Of ourse, the other thing needed is a
more close HTML integration: We need applets to be replaced
by »HTMLets«, which use the webpage (HTML) as the user
interface (for both input and output, without JavaScript
as interface code), not a special applet window.

 

[Roedy Green]

With all the continuous security leak reports about Java in
the press,

Java is being held to a much higher standard than other languages. In
15 years 3 holes were found in the Java sandbox. Other languages do
not even have a sandbox. MS sends me 2 or 3 security update a DAY for
Windows 7.

There is gross ignorance or malice going on here.

We will see if 1.7.0_13 pushed out the door 2 weeks early fixes all
the problems.

It is sort of amusing that Applets which Oracle have ignored largely
are the thing that bit them on the bum, tarnishing all of Java's
reputation.

I thing Oracle got lazy because up till recently hackers ignored Java.
Linux or Mac OS may suddenly sprout viruses when they hit some magic
level of market share.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Kevin McMurtrie]

With all the continuous security leak reports about Java in
the press, if I was Oracle, I would try to hire those
security consultants who have found security issues in Java
recently and set up a special and independent department of
maybe 7 - 14 employees whose sole purpose is to find
security holes in Java five days a week (a bonus is paid for
each hole found). Of course, /we/ know that the security
problems only relate to a specific Java runtime /in the
browser/ and that any exe file can do at least as much harm
as a Java applet, but the general audience and some executives
might get the impression that Java was »not secure«.

If, maybe 2 or 3 years later, Java is found to be quite
secure in the browser it might even get a new boost there,
when people say, »Well, JavaScript is nice, but Java s so
much more secure.« Of ourse, the other thing needed is a
more close HTML integration: We need applets to be replaced
by »HTMLets«, which use the webpage (HTML) as the user
interface (for both input and output, without JavaScript
as interface code), not a special applet window.

It would be done if it was so easy. I suspect that SecurityManager
usage has become such a tangle over time that a fix requires major
changes. The SecurityManager is used in complex Enterprise Edition
servers so its not just a simple Applet filter.

Browser plugins have always been a security risk and they're almost
always hated by consumers. It's unlikely that Java Applets will do
anything but rapidly fade away. It's easier to build a language into
the browser.

 

[Arne Vajhøj]

With all the continuous security leak reports about Java in
the press, if I was Oracle, I would try to hire those
security consultants who have found security issues in Java
recently and set up a special and independent department of
maybe 7 - 14 employees whose sole purpose is to find
security holes in Java five days a week (a bonus is paid for
each hole found).

I would expect Oracle to already have the necessary skill sets
in house.

It is probably more a matter of priority. "Let us stop
work on Java 8 that we have good paying customers that
want and make everyone to work on applet security
even though we are not making a cent and never will
on applets": can be a tough sell to management.

But the number of security fixes in 7u13 do indicate that
that the PR aspect seems to have gotten senior managements
attention at Oracle.

Arne

 

[Arne Vajhøj]

Browser plugins have always been a security risk and they're almost
always hated by consumers. It's unlikely that Java Applets will do
anything but rapidly fade away. It's easier to build a language into
the browser.

I would say that anything that executes client side comes with a risk
of security holes.

Whether it is a plugin (has to be downloaded separately) or build into
the browser (is downloaded with the browser) should really not matter.

Arne

 

[Arne Vajhøj]

Of ourse, the other thing needed is a
more close HTML integration: We need applets to be replaced
by »HTMLets«, which use the webpage (HTML) as the user
interface (for both input and output, without JavaScript
as interface code), not a special applet window.

Java applets already have access to the HTML DOM.

Arne

 

[Stefan Ram]

Java applets already have access to the HTML DOM.

If you refer to Live Connect: This needs JavaScript AFAIK.
Or what else did you think of?

Moreover, what would be nice, would be also Java Listeners
for web page events, like

<form name="input" action="MyJavaClass.class" method="java">
Username: <input type="text" name="user">
<input type="submit" value="Submit">

, where »MyJavaClass« is a class that implements the
interface »HTMLFormListener« (to be defined) and gets the
form data (here, "user") via the HTMLFormEvent (to be defined).

 

[Arne Vajhøj]

If you refer to Live Connect: This needs JavaScript AFAIK.
Or what else did you think of?

Moreover, what would be nice, would be also Java Listeners
for web page events, like

<form name="input" action="MyJavaClass.class" method="java">
Username: <input type="text" name="user">
<input type="submit" value="Submit">

, where »MyJavaClass« is a class that implements the
interface »HTMLFormListener« (to be defined) and gets the
form data (here, "user") via the HTMLFormEvent (to be defined).

<applet code="htmldemldStyle.class" codebase="." archive="oldstyle.jar"
name="myapplet" width="1" height="1" mayscript>
</applet>
<form name="myform">
<input type="text" name="myfield1">
<br>
<input type="text" name="myfield2">
<br>
<input type="text" name="myfield3">
<br>
<input type="submit" value="Add" onclick="document.myapplet.calc();
return false">
</form>

package htmldemo;

import javax.swing.JApplet;

import netscape.javascript.JSObject;

public class OldStyle extends JApplet {
public void calc() {
JSObject window = JSObject.getWindow(this);
JSObject doc = (JSObject)window.getMember("document");
JSObject myform = (JSObject)doc.getMember("myform");
JSObject myfield1 = (JSObject)myform.getMember("myfield1");
JSObject myfield2 = (JSObject)myform.getMember("myfield2");
JSObject myfield3 = (JSObject)myform.getMember("myfield3");
int val1 =
Integer.parseInt(myfield1.getMember("value").toString());
int val2 =
Integer.parseInt(myfield2.getMember("value").toString());
int val3 = val1 + val2;
myfield3.setMember("value", Integer.toString(val3));
}
}

or:

<applet code="htmldemo.NewStyle.class" codebase="." archive="newstyle.jar"
name="myapplet" width="1" height="1" mayscript>
</applet>
<form>
<input type="text" id="myfield1">
<br>
<input type="text" id="myfield2">
<br>
<input type="text" id="myfield3">
<br>
<input type="submit" value="Add" onclick="document.myapplet.calc();
return false">
</form>

package htmldemo;

import javax.swing.JApplet;

import org.w3c.dom.Element;
import org.w3c.dom.html.HTMLDocument;
import org.w3c.dom.html.HTMLInputElement;

import com.sun.java.browser.dom.DOMAccessException;
import com.sun.java.browser.dom.DOMAccessor;
import com.sun.java.browser.dom.DOMAction;
import com.sun.java.browser.dom.DOMService;
import com.sun.java.browser.dom.DOMUnsupportedException;

public class NewStyle extends JApplet {
public void calc() {
try {
DOMService service = DOMService.getService(this);
service.invokeAndWait(new DOMAction() {
public Object run(DOMAccessor accessor) {
HTMLDocument doc = (HTMLDocument)
accessor.getDocument(NewStyle.this);
HTMLInputElement myfield1 =
(HTMLInputElement)doc.getElementById("myfield1");
HTMLInputElement myfield2 =
(HTMLInputElement)doc.getElementById("myfield2");
HTMLInputElement myfield3 =
(HTMLInputElement)doc.getElementById("myfield3");
int val1 = Integer.parseInt(myfield1.getValue());
int val2 = Integer.parseInt(myfield2.getValue());
int val3 = val1 + val2;
myfield3.setValue(Integer.toString(val3));
return null;
}
});
} catch (DOMUnsupportedException e) {
e.printStackTrace();
} catch (DOMAccessException e) {
e.printStackTrace();
}
}
}

At least the first stuff is intended to be used with JavaScript,
but there are not really any JavaScript involved.

Arne

 

[Stefan Ram]

import netscape.javascript.JSObject; (...)
import com.sun.java.browser.dom.DOMAccessException;

Thanks for theses interesting examples, though it seems that
- as far as I understand it - these are not classes that are
guaranteed to be part of Java SE.

 

[Arne Vajhøj]

Thanks for theses interesting examples, though it seems that
- as far as I understand it - these are not classes that are
guaranteed to be part of Java SE.

Not very clear.

The documentation is here:
http://docs.oracle.com/javase/7/docs/jre/api/plugin/dom/index.html

http://docs.oracle.com/javase/tutorial/deployment/applet/invokingJavaScriptFromApplet.html
http://www.oracle.com/technetwork/java/javase/plugin2-142482.html

In:
http://docs.oracle.com/javase/7/docs/
it is in JRE but not in SE API.

I would interpret it as that it is supported with Oracle Java,
but no guarantee for IBM Java etc..

Arne

 

[Arne Vajhøj]

Not very clear.

The documentation is here:
http://docs.oracle.com/javase/7/docs/jre/api/plugin/dom/index.html

http://docs.oracle.com/javase/tutorial/deployment/applet/invokingJavaScriptFromApplet.html

http://www.oracle.com/technetwork/java/javase/plugin2-142482.html

In:
http://docs.oracle.com/javase/7/docs/
it is in JRE but not in SE API.

I would interpret it as that it is supported with Oracle Java,
but no guarantee for IBM Java etc..

Looking at my own link, then it looks as if the NewStyle should
be done as:

package htmldemo;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

import javax.swing.JApplet;

import org.w3c.dom.html.HTMLDocument;
import org.w3c.dom.html.HTMLInputElement;

public class NewStyle extends JApplet {
public void calc() {
try {
Class<?> c = Class.forName("com.sun.java.browser.plugin2.DOM");
Method m = c.getMethod("getDocument", new Class[] {
java.applet.Applet.class });
HTMLDocument doc = (HTMLDocument)m.invoke(null, new Object[] { this });
HTMLInputElement myfield1 =
(HTMLInputElement)doc.getElementById("myfield1");
HTMLInputElement myfield2 =
(HTMLInputElement)doc.getElementById("myfield2");
HTMLInputElement myfield3 =
(HTMLInputElement)doc.getElementById("myfield3");
int val1 = Integer.parseInt(myfield1.getValue());
int val2 = Integer.parseInt(myfield2.getValue());
int val3 = val1 + val2;
myfield3.setValue(Integer.toString(val3));
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
}
}

Arne