Java-Applets und Java WebStart-Anwendungen signieren: Unterschied zwischen den Versionen

Aus Byte-Welt Wiki
Zur Navigation springenZur Suche springen
K (Anwendung signieren)
K
 
(7 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 +
'''Autor: Gernot Segieth'''
 +
 +
'''Java Webstart ist ab Java 11 nicht mehr Teil des JDK.''' -> (Siehe [[Java_Web_Start_(TM)#Webstart-Alternativen|Webstart-Alternativen]])
 +
 
=Anwendung signieren=
 
=Anwendung signieren=
{{In Arbeit}}
 
 
'''Java-Applets haben seit Java 7 Update 51 keine Rechte mehr auf dem Gastsystem! Es muss mindestens eine Anpassung der Sicherheitseinstellungen im Java Control Panel erfolgen.'''<br>
 
'''Java-Applets haben seit Java 7 Update 51 keine Rechte mehr auf dem Gastsystem! Es muss mindestens eine Anpassung der Sicherheitseinstellungen im Java Control Panel erfolgen.'''<br>
 
Der Artikel [[Java Applets und Java Web Start-Anwendungen starten - ab Java 7 Update 51]] befasst sich eingehender mit der Inbetriebnahme von Java-Applets.
 
Der Artikel [[Java Applets und Java Web Start-Anwendungen starten - ab Java 7 Update 51]] befasst sich eingehender mit der Inbetriebnahme von Java-Applets.
Zeile 7: Zeile 10:
 
Für Applikationen erlaubte Dinge, wie Ports öffnen, sensible oder persönliche Daten aus dem [[Client]]-PC auslesen oder die VM beenden, sind einem unsignierten Applet ebenfalls untersagt.
 
Für Applikationen erlaubte Dinge, wie Ports öffnen, sensible oder persönliche Daten aus dem [[Client]]-PC auslesen oder die VM beenden, sind einem unsignierten Applet ebenfalls untersagt.
  
Ein nicht signiertes Applet wird daher bei einem unerlaubten Zugriff immer eine [http://www.google.de/search?btnI&q=site:docs.oracle.com/javase/7/docs/api/%20inurl:AccessControlException java.security.AccessControlException] werfen.
+
Die [[JRE]] wird daher bei einem unerlaubten Zugriff eines nicht signierten Applets immer eine [http://www.google.de/search?btnI&q=site:docs.oracle.com/javase/7/docs/api/%20inurl:AccessControlException java.security.AccessControlException] werfen.
  
 
  '''Hinweis: Signierte Applets können jedoch erweiterte Rechte auf dem Client erhalten.'''
 
  '''Hinweis: Signierte Applets können jedoch erweiterte Rechte auf dem Client erhalten.'''
Zeile 42: Zeile 45:
 
  '''Hinweis: Wenn die Anwendung mit einem selbst erzeugten Zertifikat signiert wurde, wird der Hersteller immer als 'UNKNOWN' ausgewiesen.'''
 
  '''Hinweis: Wenn die Anwendung mit einem selbst erzeugten Zertifikat signiert wurde, wird der Hersteller immer als 'UNKNOWN' ausgewiesen.'''
  
 
{{In Arbeit}}
 
 
Hier kannst du auch ein signiertes Applet testen. Es wird einige System-Informationen aus deinem System lesen und anzeigen, wenn du den Zugriff gestattest.
 
Hier kannst du auch ein signiertes Applet testen. Es wird einige System-Informationen aus deinem System lesen und anzeigen, wenn du den Zugriff gestattest.
 
Zugriffe, die erweiterte Rechte benötigen sind im Applet pink dargestellt. (Link wird nachgereicht!)
 
Zugriffe, die erweiterte Rechte benötigen sind im Applet pink dargestellt. (Link wird nachgereicht!)
Zeile 170: Zeile 171:
  
 
'''Für Webstart-Anwendungen''' müsste noch die JNLP-Datei angepasst werden, damit sie mit Annahme des Zertifikats (Vertrauenserklärung) alle Rechte des Benutzers auf seinem Rechner erhält:<br>
 
'''Für Webstart-Anwendungen''' müsste noch die JNLP-Datei angepasst werden, damit sie mit Annahme des Zertifikats (Vertrauenserklärung) alle Rechte des Benutzers auf seinem Rechner erhält:<br>
<code=xml>
+
<syntaxhighlight lang="xml">
 
<security>
 
<security>
 
   <all-permissions/>
 
   <all-permissions/>
 
</security>
 
</security>
</code=xml>
+
</syntaxhighlight>
  
 
Weitere Infos: [http://download.oracle.com/javase/6/docs/technotes/guides/jar/jarGuide.html JAR File Overview]
 
Weitere Infos: [http://download.oracle.com/javase/6/docs/technotes/guides/jar/jarGuide.html JAR File Overview]
Zeile 182: Zeile 183:
 
  com.sun.deploy.net.JARSigningException: Unsignierter Eintrag in Ressource: <Jar file>
 
  com.sun.deploy.net.JARSigningException: Unsignierter Eintrag in Ressource: <Jar file>
 
Wenn es Dateinamen mit Umlauten in der Jar-Datei gibt, kann es passieren, dass diese nicht signiert werden (können).<br>
 
Wenn es Dateinamen mit Umlauten in der Jar-Datei gibt, kann es passieren, dass diese nicht signiert werden (können).<br>
Also sollten diese umbenannt, die referenzierenden Dateien aktualisiert und die Jar-Datei erneut signiert werden. Unter Umständen wird es notwendig, die .ds- und .dsa-Dateien aus dem META-INF-Verzeichnis der Jar-Datei zu löschen, damit beim erneuten Signieren saubere Schlüsseldateien erzeugt werden könnnen.
+
Also sollten diese umbenannt, die referenzierenden Dateien aktualisiert, das Proramm neu kompiliert und die Jar-Datei erneut signiert werden. Unter Umständen wird es notwendig, die .ds- und .dsa-Dateien aus dem META-INF-Verzeichnis der Jar-Datei zu löschen, damit beim erneuten Signieren saubere Schlüsseldateien erzeugt werden könnnen.
  
 
=Die Alternative=
 
=Die Alternative=
Zeile 190: Zeile 191:
  
 
=Weiterführende Links=
 
=Weiterführende Links=
*[http://java.sun.com/docs/books/tutorial/deployment/jar/intro.html Understanding Signing and Verification (The Java™ Tutorials > Deployment > Packaging Programs in JAR Files)]
+
*[https://docs.oracle.com/javase/tutorial/deployment/jar/intro.html The Java™ Tutorials > Understanding Signing and Verification]
 
*[http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html keytool-Key and Certificate Management Tool]
 
*[http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html keytool-Key and Certificate Management Tool]
 
*[http://download.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html jarsigner-JAR Signing and Verification Tool]
 
*[http://download.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html jarsigner-JAR Signing and Verification Tool]
Zeile 196: Zeile 197:
 
*[http://docs.oracle.com/javase/1.4.2/docs/guide/jws/developersguide/syntax.html JNLP File Syntax]
 
*[http://docs.oracle.com/javase/1.4.2/docs/guide/jws/developersguide/syntax.html JNLP File Syntax]
  
 
+
[[Kategorie:Java Applets]]
[[Kategorie:Java]]
 
 
[[Kategorie:Java Verschiedenes]]
 
[[Kategorie:Java Verschiedenes]]
 
[[Kategorie:Tutorials (Java)]]
 
[[Kategorie:Tutorials (Java)]]
 
--[[Benutzer:L-ectron-X | L-ectron-X]] (15.05.2005, 18:58)
 
--[[Benutzer:L-ectron-X | L-ectron-X]] (15.05.2005, 18:58)

Aktuelle Version vom 14. November 2021, 17:00 Uhr

Autor: Gernot Segieth

Java Webstart ist ab Java 11 nicht mehr Teil des JDK. -> (Siehe Webstart-Alternativen)

Anwendung signieren

Java-Applets haben seit Java 7 Update 51 keine Rechte mehr auf dem Gastsystem! Es muss mindestens eine Anpassung der Sicherheitseinstellungen im Java Control Panel erfolgen.
Der Artikel Java Applets und Java Web Start-Anwendungen starten - ab Java 7 Update 51 befasst sich eingehender mit der Inbetriebnahme von Java-Applets.

Unsignierte Applets haben u.a. keinen Zugriff auf die lokale Datei- und Verzeichnisebene des Clients und dürfen sich nur zu dem Rechner verbinden, von dem sie auch heruntergeladen wurden. Für Applikationen erlaubte Dinge, wie Ports öffnen, sensible oder persönliche Daten aus dem Client-PC auslesen oder die VM beenden, sind einem unsignierten Applet ebenfalls untersagt.

Die JRE wird daher bei einem unerlaubten Zugriff eines nicht signierten Applets immer eine java.security.AccessControlException werfen.

Hinweis: Signierte Applets können jedoch erweiterte Rechte auf dem Client erhalten.
Häufig ist zu beobachten, dass Programmierer in ihren Applets Bilder mit den verkehrten Methoden einbinden. Dazu mehr unter Grafikdateien laden und anzeigen.
Hinweis: Zum Signieren eines Java-Applets muss dieses in einer Jar-Datei gespeichert sein.

Möglichkeiten der Signierung

Es gibt zwei Möglichkeiten eine Java-Anwendung zu signieren:

  1. Die kostenpflichtige Ausstellung eines Zertifikats von einem darauf spezialisierten Unternehmen, wie z.B. VeriSign (ehem. Thawte). So ein Zertifikat kann mehrere 100 Dollar kosten.
  2. Die Signierung des Programms durch den Programmierer selbst.

Dabei wird mit den Tools des JDK/SDK ein Zertifikat erzeugt. Auch die Erzeugung eines Zertifikats mittels OpenSSL ist denkbar.

In beiden Fällen öffnet sich vor dem Start der Anwendung ein Fenster mit einem Sicherheitshinweis, welches sich vom Benutzer die Erlaubnis einholt, eventuell potenziell unsichere/gefährliche Operationen auf seinem System durchführen zu dürfen.
Der Benutzer selbst muss entscheiden, ob er dem Applet vertrauen möchte, oder nicht.

Warn-, Hinweis- oder Informationsdialoge

Die Dialoge vor dem Start eines Java-Applets sehen sehr verschieden aus und unterscheiden sich in ihrer optischen Auffälligkeit.
Je aggressiver der Warndialog optisch dargestellt wird, um so weniger sollte man dem Applet dahinter vertrauen.

Der Informationsdialog, dass ein Applet gestartet werden soll, welches ein beglaubigtes Zertifikat besitzt, sie so aus:

Oracle applet.png


Der Warndialog, dass ein Applet gestartet werden soll, dessen Herkunft nicht beglaubigt wurde, also das Applet selbst signiert wurde, sie so aus:

Sicherheitswarnung2.png


Hinweis: Die Informationsdialoge sind in keinem Fall modifizierbar oder unterdrückbar.
Hinweis: Wenn die Anwendung mit einem selbst erzeugten Zertifikat signiert wurde, wird der Hersteller immer als 'UNKNOWN' ausgewiesen.

Hier kannst du auch ein signiertes Applet testen. Es wird einige System-Informationen aus deinem System lesen und anzeigen, wenn du den Zugriff gestattest. Zugriffe, die erweiterte Rechte benötigen sind im Applet pink dargestellt. (Link wird nachgereicht!)

SignTool für Windows

Folgende kleine Batchdatei, kann das komfortable Erstellen einer Jar-Datei und anschließende Signieren eines Applets vereinfachen. Einfach die blauen Texte der Datei mit Hilfe eines Texteditors modifizieren, unter einem Namen wie bspw. SignTool.bat in deinem Projektverzeichnis speichern und per Doppelklick ausführen.

Hinweis: Die Batchdatei darf auf keinen Fall den Namen eines der Tools aus dem JDK erhalten!
@echo off
rem * SignTool by L-ectron-X ( byte-welt.net )
rem **************************************************************************
rem * Ablauf beim Signieren
rem *
rem * Erzeugen eines eigenen Schlüssels
rem * keytool -genkeypair -alias Signer -dname "cn=Dein Name, c=de"
rem *
rem * Erzeugen eines verschlüsselten Zertifikats:
rem * keytool -selfcert -alias Signer -dname "cn=Dein Name, c=de"
rem * Gib anschließend Dein Passwort ein.
rem *
rem * keytool unterstützt weitere Angaben:
rem * CN=commonName
rem * OU=organizationUnit
rem * O=organizationName
rem * L=localityName
rem * S=stateName
rem * C=country
rem *
rem * Mehr über keytool: http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html 
rem *
rem * Signieren des Applets mit Hilfe des Tools jarsigner
rem * jarsigner signed.jar Signer
rem * Und noch einmal dein Passwort eingeben.
rem ***************************************************************************
echo = SignTool =
echo Dieses Tool hilft beim Erzeugen von signierten jar-Dateien
echo.
echo Schritt 1: jar-Dateien erzeugen
echo -------------------------------
rem Pfad zum SDK setzen rem --> optional, (auskommentieren, wenn eine Umgebungsvariable gesetzt wurde) set java_home=.;C:\Programme\Java\jdk1.8.0\bin set path=.;%path%;%java_home%
echo Manifestdatei erzeugen... echo Manifest-Version: 1.0>manifest.mf echo Created-by: SignTool by L-ectron-X - byte-welt.net>>manifest.mf
rem --> Anpassen, wenn eine Applikation statt eines Applets signiert werden soll! rem * Applikationen brauchen die Main-Class-Definition im Manifest. Dann ist das rem zu entfernen. rem echo Main-Class: package.MainClass>>manifest.mf
rem --> Anpassen, wenn das Applet bzw. die Applikation Resourcen weiterer Jar-Dateien benutzt! rem echo Class-Path: ./lib/External.jar>>manifest.mf
rem --> Anpassen, wenn eine Webstart-Applikation oder ein Applet, JNLP benutzt, muss der Wert mit dem im JNLP-File übereinstimmen. rem * Es wird zwischen den Werten sandbox und all-permissions unterschieden. rem * Wenn im Applet-Tag keine Permission angegeben wurde, gilt der Standardwert: all-permissions für signierte, sandbox für unsignierte Applets rem * Wenn das Permission-Attribut im Manifest nicht angegeben wird, wird die Anwendung blockiert! rem * Mehr dazu unter http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/manifest.html#permissions echo Permissions: sandbox>>manifest.mf
rem --> Anpassen, wenn verhindert werden soll, dass die Anwendung auf einer anderen Domain 're-deployed' wird. rem * Die Domain muss mit dem Speicherort der Anwendung übereinstimmen, sonst wird die Anwendung blockiert. rem * Mehr dazu unter http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/manifest.html#codebase rem echo Codebase: http://byte-welt.net>>manifest.mf
rem --> Anpassen, es wird empfohlen, den Namen der Anwendung anzugeben. rem * Der Name wird im Warndialog angezeigt und soll dem Benutzer die Entscheidung erleichtern, der Anwendung zu vertrauen. rem * Mehr dazu unter http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/manifest.html#app_name rem echo Application-Name: Hallo Welt!>>manifest.mf
rem * Leerzeile nicht vergessen! echo.>>manifest.mf
if exist *.jar goto key rem * Wenn bereits eine Jar-Datei im Verzeichnis liegt, wird das Erzeugen einer Jar-Datei uebersprungen. echo jar-Datei mit angegebenen Parametern erzeugen... rem --> anpassen! rem * In folgendem Beispiel werden alle .class-Dateien mit Package (de.domain.applets) und die Verzeichnisse bilder und etc rem * mit ins jar-Archiv gepackt. jar cfmv MeinJar.jar manifest.mf de/domain/applets/*.class bilder etc
:key echo. echo Schritt 2: Schluessel generieren echo ----------------------------------------------- rem --> anpassen! keytool -genkeypair -alias Signer -dname "cn=Dein Name, c=de"
echo. echo Schritt 3: Zertifikat generieren echo ----------------------------------------------- rem --> anpassen! rem -validity 18250 (365 Tage x 50) erzeugt ein 50 Jahre gültiges Zertifikat keytool -selfcert -validity 3650 -alias Signer -dname "cn=Dein Name, c=de"
if not exist *.jar goto error
echo. echo Schritt 4: jar-Datei signieren echo ------------------------------ echo jarsigner erwartet hier nochmals dein Passwort. rem --> anpassen! jarsigner MeinJar.jar Signer
echo. echo Schritt 5: Zertifikat testen echo ---------------------------- rem --> anpassen! jarsigner -verify -verbose -certs MeinJar.jar goto end
:error echo. echo Es wurde keine jar-Datei zum Signieren gefunden. echo Die Erzeugung der jar-Datei ist moeglicherweise fehlgeschlagen. echo Pruefe deine Modifikationen in der SignTool-Batchdatei! goto console
:end if not exist manifest.mf goto console echo. rem Manifest von Festplatte löschen del manifest.mf echo Zur Kontrolle: Ein paar Zeilen weiter oben sollte nun 'jar signed' stehen! echo Das ist die Bestaetigung dafür, dass die Jar-Datei erfolgreich signiert wurde.
:console rem Console für Ausgaben noch geöffnet lassen echo. pause

In deinem Projekt-Verzeichnis sollte vorzugsweise noch keine jar-Datei angelegt sein, das Tool wird dann auch eine korrekte jar-Datei aus deinen .class-Dateien erzeugen können. Auch wenn Du eine jar-Datei schon erzeugt hast und nur die Signierung mit Hilfe dieser Batchdatei durchführen möchtest, genügt die Modifikation der Batchdatei an den ausgewiesenen Stellen. Wenn du bisher noch keine Signierung gemacht hast, wirst du im Verlauf des Batchdatei-Ablaufes nach einem Passwort gefragt, welches du selbst wählen kannst. Merke es dir gut. Wenn du es vergisst, kannst du so lange keine weiteren Applets signieren, bis du die .keystore-Datei aus deinem Benutzer-Verzeichnis gelöscht hast.

Damit das nun in einer Jar-Datei verpackte und signierte Applet auch ausgeführt werden kann, muss die HTML-Datei angepasst werden:
Einbinden von Applets in HTML-Dateien

Für Webstart-Anwendungen müsste noch die JNLP-Datei angepasst werden, damit sie mit Annahme des Zertifikats (Vertrauenserklärung) alle Rechte des Benutzers auf seinem Rechner erhält:

<security>
   <all-permissions/>
</security>

Weitere Infos: JAR File Overview

Fehlermeldungen

  • Der Interpreter meldet, dass in einer signierten Jar-Datei ein unsignierter Eintrag gefunden wurde:
com.sun.deploy.net.JARSigningException: Unsignierter Eintrag in Ressource: <Jar file>

Wenn es Dateinamen mit Umlauten in der Jar-Datei gibt, kann es passieren, dass diese nicht signiert werden (können).
Also sollten diese umbenannt, die referenzierenden Dateien aktualisiert, das Proramm neu kompiliert und die Jar-Datei erneut signiert werden. Unter Umständen wird es notwendig, die .ds- und .dsa-Dateien aus dem META-INF-Verzeichnis der Jar-Datei zu löschen, damit beim erneuten Signieren saubere Schlüsseldateien erzeugt werden könnnen.

Die Alternative

Wer nicht signieren möchte, kann das Problem auch mit der JNLP-API angehen. Hier ein Beispiel, wie man ohne Signieren vom Client lesen und auch auf ihn schreiben kann:

Weiterführende Links

-- L-ectron-X (15.05.2005, 18:58)