Applets security and HTMLets

Discussion in 'Java' started by Stefan Ram, Feb 2, 2013.

  1. Stefan Ram

    Stefan Ram Guest

    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.
     
    Stefan Ram, Feb 2, 2013
    #1
    1. Advertising

  2. Stefan Ram

    Roedy Green Guest

    On 2 Feb 2013 14:45:17 GMT, -berlin.de (Stefan Ram) wrote,
    quoted or indirectly quoted someone who said :

    > 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
     
    Roedy Green, Feb 2, 2013
    #2
    1. Advertising

  3. In article <-berlin.de>,
    -berlin.de (Stefan Ram) wrote:

    > 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.
    --
    I will not see posts from Google because I must filter them as spam
     
    Kevin McMurtrie, Feb 2, 2013
    #3
  4. Stefan Ram

    Arne Vajhøj Guest

    On 2/2/2013 9:45 AM, Stefan Ram wrote:
    > 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, Feb 2, 2013
    #4
  5. Stefan Ram

    Arne Vajhøj Guest

    On 2/2/2013 11:55 AM, Kevin McMurtrie wrote:
    > 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, Feb 2, 2013
    #5
  6. Stefan Ram

    Arne Vajhøj Guest

    On 2/2/2013 9:45 AM, Stefan Ram wrote:
    > 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
     
    Arne Vajhøj, Feb 2, 2013
    #6
  7. Stefan Ram

    Stefan Ram Guest

    Arne Vajhøj <> writes:
    >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).
     
    Stefan Ram, Feb 2, 2013
    #7
  8. Stefan Ram

    Arne Vajhøj Guest

    On 2/2/2013 12:49 PM, Stefan Ram wrote:
    > Arne Vajhøj <> writes:
    >> 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).


    <applet code="htmldemo_OldStyle.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
     
    Arne Vajhøj, Feb 2, 2013
    #8
  9. Stefan Ram

    Stefan Ram Guest

    Arne Vajhøj <> writes:
    >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.
     
    Stefan Ram, Feb 2, 2013
    #9
  10. Stefan Ram

    Arne Vajhøj Guest

    On 2/2/2013 2:14 PM, Stefan Ram wrote:
    > Arne Vajhøj <> writes:
    >> 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.


    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, Feb 2, 2013
    #10
  11. Stefan Ram

    Arne Vajhøj Guest

    On 2/2/2013 3:25 PM, Arne Vajhøj wrote:
    > On 2/2/2013 2:14 PM, Stefan Ram wrote:
    >> Arne Vajhøj <> writes:
    >>> 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.

    >
    > 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
     
    Arne Vajhøj, Feb 2, 2013
    #11
    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. Andre M. Maier
    Replies:
    0
    Views:
    482
    Andre M. Maier
    Dec 3, 2003
  2. golem

    applets - security

    golem, Apr 19, 2004, in forum: Java
    Replies:
    3
    Views:
    357
    Mark Preston
    Apr 20, 2004
  3. Stefan Willmert

    Applets, Security, Sockets General Question

    Stefan Willmert, Jun 5, 2004, in forum: Java
    Replies:
    3
    Views:
    530
    Stefan Willmert
    Jun 5, 2004
  4. SPG
    Replies:
    1
    Views:
    396
    Mickey Segal
    Aug 25, 2004
  5. Myriam Abramson

    Applets, JAXB and security policy

    Myriam Abramson, Dec 3, 2007, in forum: Java
    Replies:
    3
    Views:
    1,430
    Andrew Thompson
    Dec 4, 2007
Loading...

Share This Page