From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- .../hjp5/html/k100304.html | 193 +++++++++++++++++++++ 1 file changed, 193 insertions(+) create mode 100644 Master/Reference Architectures and Patterns/hjp5/html/k100304.html (limited to 'Master/Reference Architectures and Patterns/hjp5/html/k100304.html') diff --git a/Master/Reference Architectures and Patterns/hjp5/html/k100304.html b/Master/Reference Architectures and Patterns/hjp5/html/k100304.html new file mode 100644 index 0000000..64cefd4 --- /dev/null +++ b/Master/Reference Architectures and Patterns/hjp5/html/k100304.html @@ -0,0 +1,193 @@ + + + +Handbuch der Java-Programmierung, 5. Auflage + + + + + + + + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage +
 <<  +  <   +  >   + >>  + API  +Kapitel 48 - Sicherheit und Kryptographie +
+
+ + + + +

48.2 Sicherheitsmechanismen in Java

+
+ +
+ + + + +

48.2.1 Sprachsicherheit

+ +

+Java wurde von Anfang an mit höheren Sicherheitsansprüchen +entworfen, als dies üblicherweise bei Programmiersprachen der +Fall ist. Einer der Hauptgründe dafür war der Wunsch, den +Aufruf von Applets, die aus dem Internet geladen wurden, so sicher +wie möglich zu machen. Selbst bösartige Applets sollten +nicht in der Lage sein, ernsthafte Angriffe auf den Computer, das +Betriebssystem oder die Ressourcen des Anwenders auszuführen. + +

+Sicherheit beginnt in Java schon bei der Implementierung der Sprache. +Anders als in C oder C++ gibt es beispielsweise keine direkten Zugriffe +auf den Hauptspeicher und keine Pointerarithmetik. Das Memory-Management +arbeitet vollautomatisch. Sicherheitslücken, die durch (provozierte) +Speicherüberläufe verursacht werden, sind damit nicht ohne +weiteres möglich. + +

+Alle Typkonvertierungen werden zur Laufzeit geprüft und unerlaubte +Umwandlungen von vorne herein ausgeschlossen. Auch Zugriffe auf Array-Elemente +und Strings werden grundsätzlich auf Einhaltung der Bereichsgrenzen +geprüft. Zugriffe, die außerhalb des erlaubten Bereichs +liegen, führen nicht zu undefiniertem Verhalten, sondern werden +definiert abgebrochen und lösen eine Ausnahme aus. + +

+Beim Laden von Bytecode über das Netz wird dieser vor der Ausführung +von einem Bytecode-Verifier untersucht. +Auf diese Weise wird beispielsweise sichergestellt, dass nur gültige +Opcodes verwendet werden, dass alle Sprunganweisungen auf den Anfang +einer Anweisung zeigen, dass alle Methoden mit korrekten Signaturen +versehen sind und dass Ausdrücke korrekt typisiert sind. Zudem +implementiert der Klassenlader einen lokalen Namensraum, der verhindert, +dass bestehende Klassen verändert oder ersetzt werden können. + + + + +

48.2.2 Das Sandbox-Konzept

+ +

+Traditionell wurde in Java zwischen lokalem Code und solchem, der +aus dem Netz geladen wird, bezüglich seiner Sicherheitsanforderungen +rigoros unterschieden. Während lokalem Code (also Applikationen +und von der Festplatte geladenen Applets) der Zugriff auf alle verfügbaren +Ressourcen gestattet ist, dürfen Applets, die aus dem Netz geladen +wurden, nur einen kleinen Teil davon verwenden. Sie halten sich gewissermaßen +in einem Sandkasten auf, in dem sie nur ungefährliche Spielzeuge +verwenden und keinen ernsthaften Schaden anrichten können (daher +der Name »Sandbox«). + +

+Zu den »gefährlichen Spielzeugen«, die nicht verwendet +werden dürfen, zählen: +

+

+ + + + + + + + + +
+ +

+Benötigte ein Applet Zugriff auf diese Ressourcen, gab es im +JDK 1.0 die Möglichkeit, die zugehörigen Dateien auf der +lokalen Festplatte abzulegen. Denn wenn das Applet zur Ausführung +nicht aus dem Netz, sondern aus den lokalen Dateien gestartet wurde, +galt es automatisch als vertrauenswürdig und hatte Zugriff auf +alle ansonsten verbotenen Ressourcen.

 + + + + +
 Hinweis 
+
+ + + + +

48.2.3 Veränderungen im JDK 1.1 und 1.2

+ +

+Mit dem JDK 1.1 wurde eine neue Möglichkeit eingeführt, +Applets Zugriff auf geschützte Ressourcen zu ermöglichen. +Dazu müssen alle zum Applet gehörenden Dateien in eine jar-Datei +verpackt und mit einer digitalen Unterschrift versehen werden. Wird +der Unterzeichner auf dem ausführenden Computer als vertrauenswürdig +angesehen (indem sein öffentlicher Schlüssel an geeigneter +Stelle bekanntgemacht wurde), kann das Applet die Sandbox verlassen +und hat Zugriff auf alle geschützten Ressourcen. + +

+Mit dem JDK 1.2 wurde dieses Konzept weiter verfeinert. Während +es im JDK 1.1 schwierig war, die Zugriffsbeschränkungen schrittweise +zu lockern, ist das nun viel einfacher. Die Zugriffsbeschränkungen +sind konfigurierbar und können mit Hilfe einer Policy-Datei +auch ohne Programmänderungen angepasst werden. Sie können +wahlweise davon abhängig gemacht werden, von wem die Signatur +stammt, als auch davon, woher das Applet geladen wurde. Zudem wurde +die prinzipielle Unterscheidung zwischen lokalem und netzwerkbasiertem +Code aufgegeben. Obwohl die Sicherheitseinstellungen so konfiguriert +werden könnten, dass lokalem Code voller Zugriff auf alle Ressourcen +gewährt wird, ist das standardmäßig nicht mehr der +Fall. +

+ + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage, Addison +Wesley, Version 5.0.1 +
 <<  +  <   +  >   + >>  + API  +© 1998, 2007 Guido Krüger & Thomas +Stark, http://www.javabuch.de +
+ + + -- cgit v1.2.3