Editing Java applet (section)

== Security ==
{{POV section|date=November 2021}}
There were two applet types with very different security models: signed applets and unsigned applets.<ref>{{Cite web|url=https://docs.oracle.com/javase/tutorial/deployment/applet/security.html|title=What Applets Can and Cannot Do (The Java Tutorials > Deployment > Java Applets)|website=Docs.oracle.com|access-date=22 March 2022}}</ref> Starting with Java SE 7 Update 21 (April 2013) applets and Web-Start Apps are encouraged to be signed with a trusted certificate, and warning messages appear when running unsigned applets.<ref>{{Cite web|url = http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html#60|title = Java Applet & Web Start – Code Signing|access-date = 28 February 2014|publisher = Oracle}}</ref> Further, starting with Java 7 Update 51 unsigned applets were blocked by default; they could be run by creating an exception in the Java Control Panel.<ref>{{Cite web|url = http://java.com/en/download/help/appsecuritydialogs.xml|title = What should I do when I see a security prompt from Java?|access-date = 28 February 2014|publisher = Oracle}}</ref>

=== Unsigned ===<!-- I didn't really bother with cleaning up the tense of these sections: they need a full rewrite, due to substantial NPOV problems -->
Limits on unsigned applets were understood as "draconian": they have no access to the local filesystem and web access limited to the applet download site; there are also many other important restrictions. For instance, they cannot access all system properties, use their own [[class loader]], call [[native code]], execute external commands on a local system or redefine classes belonging to core packages included as part of a Java release. While they can run in a standalone frame, such frame contains a header, indicating that this is an untrusted applet. Successful initial call of the forbidden method does not automatically create a security hole as an access controller checks the entire [[Call stack|stack]] of the calling code to be sure the call is not coming from an improper location.

As with any complex system, many security problems have been discovered and fixed since Java was first released. Some of these (like the Calendar serialization security bug) persisted for many years with nobody being aware. Others have been discovered in use by malware in the wild.{{citation needed|date=September 2013}}

Some studies mention applets crashing the browser or overusing [[central processing unit|CPU]] resources but these are classified as nuisances and not as true security flaws. However, unsigned applets may be involved in combined attacks that exploit a combination of multiple severe configuration errors in other parts of the system. An unsigned applet can also be more dangerous to run directly on the server where it is hosted because while code base allows it to talk with the server, running inside it can bypass the firewall. An applet may also try [[Denial-of-service attack|DoS attacks]] on the server where it is hosted, but usually people who manage the web site also manage the applet, making this unreasonable. Communities may solve this problem via [[Code review|source code review]] or running applets on a dedicated domain.

The unsigned applet can also try to download malware hosted on originating server. However it could only store such file into a temporary folder (as it is transient data) and has no means to complete the attack by executing it. There were attempts to use applets for spreading Phoenix and Siberia exploits this way,{{citation needed|date=October 2010}} but these exploits do not use Java internally and were also distributed in several other ways.

=== Signed ===
A signed applet<ref>{{Cite web|url=https://www.informit.com/articles/article.aspx?p=433382&seqNum=2|title=Java Applet Security {{pipe}} Java 2 Platform Security {{pipe}} InformIT|website=Informit.com|access-date=22 March 2022}}</ref> contains a signature that the browser should verify through a remotely running, independent [[Certificate server|certificate authority server]]. Producing this signature involves specialized tools and interaction with the authority server maintainers. Once the signature is verified, and the user of the current machine also approves, a signed applet can get more rights, becoming equivalent to an ordinary standalone program. The rationale is that the author of the applet is now known and will be responsible for any deliberate damage.{{vague|date=October 2010}} This approach allows applets to be used for many tasks that are otherwise not possible by client-side scripting. However, this approach requires more responsibility from the user, deciding whom he or she trusts. The related concerns include a non-responsive authority server, wrong evaluation of the signer identity when issuing certificates, and known applet publishers still doing something that the user would not approve of. Hence signed applets that appeared from Java 1.1 may actually have more security concerns.

=== Self-signed ===
Self-signed applets, which are applets signed by the developer themselves, may potentially pose a security risk; java plugins provide a warning when requesting authorization for a self-signed applet, as the function and safety of the applet is guaranteed only by the developer itself, and has not been independently confirmed. Such self-signed certificates are usually only used during development prior to release where third-party confirmation of security is unimportant, but most applet developers will seek third-party signing to ensure that users trust the applet's safety.

Java security problems are not fundamentally different from similar problems of any client-side scripting platform<ref>{{Cite web|url=http://www.wiley.com/legacy/compbooks/press/mcgch1.html|title=To be fair, significantly more World Wide Web users use the Netscape product than use the Microsoft product today, though the gap appears to be closing|website=Wiley.com|access-date=2017-03-17}}</ref>{{citation needed|date=December 2015}}. In particular, all issues related to signed applets also apply to Microsoft [[ActiveX]] components.

As of 2014, self-signed and unsigned applets are no longer accepted by the commonly available Java plugins or Java Web Start. Consequently, developers who wish to deploy Java applets have no alternative but to acquire trusted certificates from commercial sources.