[JAVA] Richtlinieneinstellung zum Ausführen veralteter Applets Kampfnotizen

Obwohl Java 11 veröffentlicht wurde und die Ära, in der Äpfel nicht verwendet werden können, angebrochen ist, besteht immer noch ein Bedarf an Java-Äpfeln, um neue Funktionen zu realisieren. Es gibt verschiedene Gründe, ein Applet verwenden zu wollen, aber die meisten sind "Ich möchte eine native Verarbeitung von JavaScript durchführen". In solchen Zeiten bin ich nicht der einzige, der immer von sicherheitsrelevanten Umgebungseinstellungen abhängig ist. Ich möchte Applets nicht wirklich verwenden, aber ich musste Kompromisse eingehen und sie verwenden, und der Stress, Zeit in den Umgebungseinstellungen zu verbringen, ist nicht überwältigend. Da eine solche Erfahrung einmal ausreicht, werde ich die Suchtpunkte, auf die ich hier gestoßen bin, zusammenfassen, damit ich in Zukunft keine solche Erfahrung machen kann.

Fehlkonfiguration von java.policy

Äpfel können native Verarbeitung durchführen, die mit JavaScript nicht möglich ist. Wer das glaubt, sollte vorsichtig sein. Selbst ein Applet kann nicht ohne Einschränkungen ausgeführt werden. Sie müssen daher eine Sicherheitsausnahme in "$ JRE_HOME / lib / security / java.policy" festlegen. Andernfalls wird eine Laufzeitausnahme angezeigt, wenn Sie versuchen, eine native Verarbeitung (z. B. das Schreiben einer Datei) über ein Applet durchzuführen.

Wenn Sie möchten, dass es vorerst funktioniert, geben Sie allen Einträgen alle Berechtigungen java.security.AllPermission;.

grant {
	permission java.security.AllPermission;
}

Begrenzt durch codeBase

Wenn Sie nur für einen bestimmten Eintrag festlegen möchten, schreiben Sie codeBase. Die Spezifikation ändert sich abhängig davon, ob sie auf einem lokalen Laufwerk gespeichert oder aus dem Web heruntergeladen und ausgeführt wird. Weitere Informationen finden Sie in der offiziellen Java-Dokumentation.

https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/PolicyFiles.html

Mit Genehmigung eingeschränkt

Wenn Sie nur bestimmte Berechtigungen erteilen möchten, geben Sie die Berechtigung java.security an. ~ Klassenname ~; `. Weitere Informationen finden Sie in der offiziellen Java-Dokumentation.

https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/permissions.html

Fehlendes Lesen von java.policy in java.security

Wenn java.policy korrekt beschrieben wird, die Einstellungen jedoch nicht wiedergegeben werden, überprüfen Sie, ob java.policy überhaupt gelesen wird. Die Lesereihenfolge ist sehr wichtig, da java.policy die Definition in mehrere Dateien aufteilt und die Einstellungen in der Reihenfolge überschrieben werden, in der sie gelesen werden. Es gibt eine "policy.url.n" -Spezifikation zum Lesen von "java.policy" in "$ JRE_HOME / lib / security / java.security". Überprüfen Sie dies hier. Standardmäßig sollte es so aussehen:

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

Öffnen Sie für "$ {java.home}" und "$ {user.home}" nach dem Starten des Applets die "Java-Konsole", um die Eigenschaften zu überprüfen, oder erstellen Sie ein zu überprüfendes Bestätigungsprogramm.

System.out.println(System.getProperty("user.home"));

Weitere Einzelheiten zu "policy.url.n" finden Sie im offiziellen Dokument. https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/PolicyFiles.html#DefaultLocs

Code für die privilegierte Ausführung

Wenn Sie eine Berechtigungsausnahme erhalten, obwohl Sie java.policy richtig eingestellt haben, stellen Sie sicher, dass das Java-Applet unter Berücksichtigung der privilegierten Ausführung implementiert ist. Eine Verarbeitung, die zu einer Sicherheitsausnahme wird, kann nur ausgeführt werden, wenn die API "java.security.AccessController # doPrivileged" für privilegierte Blöcke verwendet wird.

In der Regel habe ich festgelegt, dass es in der Testumgebung funktioniert (AllPermission wird ohne Angabe der Codebasis in Grant angegeben), aber es ist ein Muster, das beklagt, dass es in der Produktionsumgebung nicht funktioniert. Da es sich anfühlt, als hätte es aufgehört zu funktionieren, nur weil sich die java.policy geändert hat, wird missverstanden, dass "java.policy falsch ist", aber die Implementierung des Applets ist tatsächlich schlecht.

public class SampleApplet extends Applet {
	public void hoge() {
		AccessController.doPrivileged(new PrivilegedAction<Object>() {
			@Override
			public Object run() {
				//Verarbeitung, für die eine Genehmigung erforderlich ist
				//new Robot().createScreenCapture usw.
				return null;
			}
		});
	}
}

Das offizielle Dokument über privilegierte Blöcke ist ↓↓ https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/doprivileged.html