JDK-6898850 : Allow to define more restrictions for unsigned applets in MANIFEST
  • Type: Enhancement
  • Component: deploy
  • Affected Version: 7,9
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux_redhat_5.0
  • CPU: x86
  • Submitted: 2009-11-06
  • Updated: 2017-04-06
  • Resolved: 2017-04-06
Related Reports
Relates :  
Description
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).

Comments
manifest entries of unsigned jars are generally ignored and considered meaningless. Also unsigned jars are generally now forbidden unless app is on ESL or has an DRS run rule. For those reasons I would suggest that any new manifest entry restricting access to download host be limited to signed sandbox apps.
15-02-2017

The second request here - signed sandbox applets (and applications) was implemented in 7u25 The first request is still valid - request manifest entry removing ability of app to contact download host.
28-07-2014