P5
A DESCRIPTION OF THE REQUEST :
In relation to the current proposal for using applets in Wikipedia and other similar sites (see http://strategy.wikimedia.org/wiki/Proposal:Java_applet_support) we have faced an old discussion about security concerns. While limitations for the unsigned applet are already considered "draconian", it still can talk to the web server it was downloaded from. For the huge sites like Wikipedia this means that applet can try DOS attack on the hosting server.
Not all applets need this "parent server" access functionality, and we would propose to have a possibility to disable in in jar manifest or other similar place. Manifest can be easily checked at the time the applet is uploaded.
Another interesting opportunity is to specify that actually signed applet is restricted same way as it would be unsigned one. This would allow to combine the security of both approaches, allowing more trustworthy deployment on the high traffic community sites.
JUSTIFICATION :
This change would allow to use applets in community sites where attack on the hosting server is a concern and checking of the manifest file is easy.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The manifest file has entries that can be used to disallow web access to the parent server (for unsigned applet) or to limit rights of the signed applet to the rights of the unsigned one. Hosting server can easily check the manifest for the proper entries. This has no impact of the work of the current applets.
ACTUAL -
There is one set of rights for the signed applets and another for unsigned ones. Software restrictions and signer identity cannot be combined.
CUSTOMER SUBMITTED WORKAROUND :
We are thinking about scanning the source code of the submitted applets.
The submitter writes:
> Another interesting opportunity is to specify that actually signed applet is restricted same way as
> it would be unsigned one. This would allow to combine the security of both approaches, allowing more
> trustworthy deployment on the high traffic community sites.
This could be accomplished with the addition of fine-grained permission requests to the
signed applet (see CR 6205526).
In relation to the current proposal for using applets in Wikipedia and other similar sites (see http://strategy.wikimedia.org/wiki/Proposal:Java_applet_support) we have faced an old discussion about security concerns. While limitations for the unsigned applet are already considered "draconian", it still can talk to the web server it was downloaded from. For the huge sites like Wikipedia this means that applet can try DOS attack on the hosting server.
Not all applets need this "parent server" access functionality, and we would propose to have a possibility to disable in in jar manifest or other similar place. Manifest can be easily checked at the time the applet is uploaded.
Another interesting opportunity is to specify that actually signed applet is restricted same way as it would be unsigned one. This would allow to combine the security of both approaches, allowing more trustworthy deployment on the high traffic community sites.
JUSTIFICATION :
This change would allow to use applets in community sites where attack on the hosting server is a concern and checking of the manifest file is easy.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The manifest file has entries that can be used to disallow web access to the parent server (for unsigned applet) or to limit rights of the signed applet to the rights of the unsigned one. Hosting server can easily check the manifest for the proper entries. This has no impact of the work of the current applets.
ACTUAL -
There is one set of rights for the signed applets and another for unsigned ones. Software restrictions and signer identity cannot be combined.
CUSTOMER SUBMITTED WORKAROUND :
We are thinking about scanning the source code of the submitted applets.
The submitter writes:
> Another interesting opportunity is to specify that actually signed applet is restricted same way as
> it would be unsigned one. This would allow to combine the security of both approaches, allowing more
> trustworthy deployment on the high traffic community sites.
This could be accomplished with the addition of fine-grained permission requests to the
signed applet (see CR 6205526).
- relates to
-
JDK-6205526 Fine grained and well defined levels of security and trust for java webstart and plugin
-
- Closed
-