diff options
| author | Sven Eisenhauer <sven@sven-eisenhauer.net> | 2023-11-10 15:11:48 +0100 |
|---|---|---|
| committer | Sven Eisenhauer <sven@sven-eisenhauer.net> | 2023-11-10 15:11:48 +0100 |
| commit | 33613a85afc4b1481367fbe92a17ee59c240250b (patch) | |
| tree | 670b842326116b376b505ec2263878912fca97e2 /Master/Reference Architectures and Patterns/hjp5/html/k100304.html | |
| download | Studium-master.tar.gz Studium-master.tar.bz2 | |
Diffstat (limited to 'Master/Reference Architectures and Patterns/hjp5/html/k100304.html')
| -rw-r--r-- | Master/Reference Architectures and Patterns/hjp5/html/k100304.html | 193 |
1 files changed, 193 insertions, 0 deletions
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 @@ +<html>
+<head>
+<title>
+Handbuch der Java-Programmierung, 5. Auflage
+</title>
+</head>
+<body>
+<a name="startofbody"></a>
+<script language="JavaScript" src="hjp4lib.js">
+</script>
+<script language="JavaScript">
+installKbdHandler("97,#startofbody;101,#endofbody;116,cover.html;122,k100003.html;115,search.html;105,index.html;100,JDKDOCS;112,APIDOCS;104,k100302.html;106,k100303.html;107,k100305.html;108,k100307.html");
+</script>
+<table border=0 cellpadding=0 cellspacing=1 width="100%">
+<tr bgcolor="#EEFFCC">
+<td width="7%" align=center bgcolor="#DDCC99"><a href="cover.html"> Titel </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100003.html"> Inhalt </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="search.html"> Suchen </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="index.html"> Index </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="../jdkdocs/index.html" onClick="this.href=getDocIndex()"> DOC </a>
+<td align="right">Handbuch der Java-Programmierung, 5. Auflage
+<tr bgcolor="#EEFFCC">
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100302.html"> << </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100303.html"> < </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100305.html"> > </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100307.html"> >> </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="../jdkdocs/api/index.html" onClick="this.href=getApiIndex()"> API </a>
+<td align="right">Kapitel 48 - Sicherheit und Kryptographie
+</table>
+<hr>
+
+
+<!-- Section -->
+<a name="sectlevel2id048002"></a>
+<h2>48.2 Sicherheitsmechanismen in Java </h2>
+<hr>
+<ul>
+<li><a href="k100304.html#sectlevel2id048002">48.2 Sicherheitsmechanismen in Java</a>
+<ul>
+<li><a href="k100304.html#sectlevel3id048002001">48.2.1 Sprachsicherheit</a>
+<li><a href="k100304.html#sectlevel3id048002002">48.2.2 Das Sandbox-Konzept</a>
+<li><a href="k100304.html#sectlevel3id048002003">48.2.3 Veränderungen im JDK 1.1 und 1.2</a>
+</ul>
+</ul>
+<hr>
+
+
+<!-- Section -->
+<a name="sectlevel3id048002001"></a>
+<h3>48.2.1 Sprachsicherheit </h3>
+
+<p>
+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.
+
+<p>
+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.
+
+<p>
+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.
+
+<p>
+Beim Laden von Bytecode über das Netz wird dieser vor der Ausführung
+von einem <a name="ixa103506"><i>Bytecode-Verifier</i></a> 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.
+
+
+<!-- Section -->
+<a name="sectlevel3id048002002"></a>
+<h3>48.2.2 Das <a name="ixa103507">Sandbox-Konzept</a> </h3>
+
+<p>
+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«).
+
+<p>
+Zu den »gefährlichen Spielzeugen«, die nicht verwendet
+werden dürfen, zählen:
+<ul>
+<li>der lesende und schreibende Zugriff auf Dateien des lokalen Computers,
+<li>das Öffnen von TCP/IP-Verbindungen zu einem anderen als dem
+Host, von dem das Applet geladen wurde,
+<li>das Akzeptieren von TCP/IP-Verbindungen auf privilegierten Portnummern,
+<li>das Lesen benutzerbezogener System-Properties wie »user.name«,
+»user.home«, »user.dir« oder »java.home«,
+<li>das Erzeugen eines Top-Level-Fensters ohne Warnhinweis,
+<li>das Ausführen externer Programme,
+<li>das Laden von System-Libraries,
+<li>das Beenden der virtuellen Maschine.
+</ul>
+<p>
+<table border=0 cellspacing=0 cellpadding=0 width=100%>
+<tr>
+<td width=1 align=left valign=top bgcolor="#000077"><img src="trp1_1.gif"></td>
+<td><img src="trp1_1.gif" width=2></td>
+<td valign=top width=1000>
+
+<p>
+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.</td>
+<td><img src="trp1_1.gif" width=2></td>
+<td valign=top>
+<table border=0 cellspacing=0 cellpadding=1 width=100% bgcolor="#000077">
+<tr>
+<td><font color="#FFFFFF"> Hinweis </font></td>
+</tr>
+</table>
+</td>
+<td width=1 align=left valign=top bgcolor="#000077"><img src="trp1_1.gif"></td>
+</tr>
+</table>
+
+
+<!-- Section -->
+<a name="sectlevel3id048002003"></a>
+<h3>48.2.3 Veränderungen im JDK 1.1 und 1.2 </h3>
+
+<p>
+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.
+
+<p>
+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 <a name="ixa103508"><i>Policy-Datei</i></a>
+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.
+<hr>
+<table border=0 cellpadding=0 cellspacing=1 width="100%">
+<tr bgcolor="#EEFFCC">
+<td width="7%" align=center bgcolor="#DDCC99"><a href="cover.html"> Titel </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100003.html"> Inhalt </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="search.html"> Suchen </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="index.html"> Index </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="../jdkdocs/index.html" onClick="this.href=getDocIndex()"> DOC </a>
+<td align="right">Handbuch der Java-Programmierung, 5. Auflage, Addison
+Wesley, Version 5.0.1
+<tr bgcolor="#EEFFCC">
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100302.html"> << </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100303.html"> < </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100305.html"> > </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="k100307.html"> >> </a>
+<td width="7%" align=center bgcolor="#DDCC99"><a href="../jdkdocs/api/index.html" onClick="this.href=getApiIndex()"> API </a>
+<td align="right">© 1998, 2007 Guido Krüger & Thomas
+Stark, <a href="http://www.javabuch.de">http://www.javabuch.de</a>
+</table>
+<a name="endofbody"></a>
+</body>
+</html>
|