tom Sun Nov 4 04:17:10 2001 EDT
Modified files:
/phpdoc/de/chapters security.xml
Log:
file is actual now
Index: phpdoc/de/chapters/security.xml
diff -u phpdoc/de/chapters/security.xml:1.9 phpdoc/de/chapters/security.xml:1.10
--- phpdoc/de/chapters/security.xml:1.9 Sun Aug 5 17:46:45 2001
+++ phpdoc/de/chapters/security.xml Sun Nov 4 04:17:10 2001
@@ -1,4 +1,5 @@
-<!-- up-to-date against phpdoc/en/chapters/security.xml:1.23 -->
+<?xml encoding="iso-8859-1"?>
+<!-- EN-Revision: 1.31 Maintainer: tom Status: ready -->
<chapter id="security">
<title>Sicherheit</title>
@@ -33,13 +34,66 @@
Entwicklers.
</simpara>
<simpara>
- Dieses Kapitel beschreibt die verschiedenen Kombinationen der
- Konfigurationseinstellungen und unter welchen Gegebenheiten sie sicher
- genutzt werden k�nnen. Dann beschreibt es verschiedene �berlegungen
- zur Programmierung f�r verschiedene Sicherheitsstufen, und endet mit
- einigen generellen Ratschl�gen zur Sicherheit.
+ Dieses Kapitel beginnt mit einigen generellen Ratschl�gen zur Sicherheit,
+ erkl�rt die verschiedenen Kombinationen der Konfigurationseinstellungen
+ und unter welchen Gegebenheiten sie sicher genutzt werden k�nnen, und
+ beschreibt verschiedene �berlegungen zur Programmierung f�r verschiedene
+ Sicherheitsstufen.
</simpara>
+ <sect1 id="security.general">
+ <title>Allgemeine �berlegungen</title>
+ <simpara>
+ Ein komplett sicheres System ist praktisch ein Ding der Unm�glichkeit,
+ weshalb ein unter Sicherheitsprofis oft genutzter Ansatz ist, einen
+ Mittelweg zwischen Risiko und Verwendbarkeit zu finden.
+ Wenn jede von einem Benutzer �bermittelte Variable zwei Formen von
+ biometrischer Pr�fung (wie z.B. ein Scan der Netzhaut und ein
+ Fingerabdruck) verlangen w�rde, w�re eine extrem hohe Ebene der
+ Verantwortlichkeit erreicht. Ein sehr komplexes Formular auszuf�llen
+ w�rde auch eine halbe Stunde in Anspruch nehmen, was Benutzer dazu
+ ermuntern k�nnte, Wege zur Umgehung der Sicherheitsma�nahmen zu suchen.
+ </simpara>
+ <simpara>
+ Die beste Sicherheit ist oft unaufdringlich genug um den Anforderungen
+ zu entsprechen, ohne den Benutzer an seiner Arbeit zu hindern oder den
+ Code-Autor mit �bertriebener Komplexit�t zu �berlasten. Tats�chlich
+ sind einige Sicherheitsangriffe nur die Folge von allzu strengen
+ Sicherheitsma�nahmen, was mit der Zeit nur zu deren Unterminierung
+ f�hrt.
+ </simpara>
+ <simpara>
+ Eine Phrase die es wert ist, sich an sie zu erinnern: Ein System ist
+ nur so gut wie das schw�chste Glied in der Kette. Wenn alle
+ Transaktionen mittels Zeit, Ort, Transaktionstyp, etc. streng gelogged
+ werden, der Benutzer aber nur mittels einem einzigen Cookie verifiziert
+ wird, l�sst die Zuverl�ssigkeit f�r die Bindung des Benutzers an das
+ Transaktions-Log bedrohlich nach.
+ </simpara>
+ <simpara>
+ Denken Sie w�hrend der Tests daran, dass Sie selbst f�r die einfachsten
+ Seiten nicht alle M�glichkeiten testen k�nnen. Der von Ihnen vielleicht
+ erwartete Input wird zu dem eines verstimmten Mitarbeiters oder eines
+ Crackers der Monate Zeit hat, oder einer Katze, die �ber die Tastatur
+ l�uft in keinerlei Zusammenhang stehen. Deshalb betrachten Sie Ihren
+ Code am Besten aus der logischen Perspektive um zu erkennen, wo
+ unerwartete Daten eingebracht werden k�nnen und fragen sich dann,
+ wie diese modifiziert, reduziert, oder weiter ausgef�hrt werden.
+ </simpara>
+ <simpara>
+ Das Internet ist voll von Leuten welche versuchen, sich durch
+ Entschl�sseln/zerst�ren Ihres Codes, den Zusammenbruch Ihres
+ Systems, Einsetzen von unangebrachten Inhalten, und anderen, Ihren
+ Tag interessant gestaltenden Ma�nahmen, einen Namen zu machen.
+ Es ist egal, ob Sie eine kleine oder gro�e Site haben, Sie sind
+ einfach ein Ziel wenn Sie online sind oder wenn Sie einen Server
+ haben, zu dem man eine Verbindung aufbauen kann. Viele
+ Cracker-Programme erkennen nicht die Gr��e, sondern durchsieben
+ einfach gewaltige IP Bl�cke im Netz, um Opfer zu finden. Versuchen
+ Sie, keines zu werden.
+ </simpara>
+ </sect1>
+
<sect1 id="security.cgi">
<title>CGI-Version</title>
@@ -302,10 +356,11 @@
</simpara>
<simpara>
Es gibt auch ein paar einfachere L�sungen. Mit
- <function>open_basedir()</function> k�nnen Sie kontrollieren, welche
- Verzeichnisse PHP benutzen darf oder nicht. Sie k�nnen auch einen
- Bereich nur f�r Apache einrichten, um alle webbasierten Aktivit�ten
- auf nicht-Benutzer- bzw. nicht-System-Dateien einzuschr�nken.
+ <link linkend="ini.open-basedir">open_basedir()</link> k�nnen Sie
+ kontrollieren, welche Verzeichnisse PHP benutzen darf oder nicht. Sie
+ k�nnen auch einen Bereich nur f�r Apache einrichten, um alle
+ webbasierten Aktivit�ten auf nicht-Benutzer- bzw. nicht-System-Dateien
+ einzuschr�nken.
</simpara>
</sect1>
@@ -561,13 +616,14 @@
<sect1 id="security.registerglobals">
<title>Verwendung von Register Globals</title>
<para>
- Ein Feature von PHP zur Erh�hung der Sicherheit ist die Konfiguration
- von PHP mit register_globals = off. Mit Deaktivierung der M�glichkeit,
- irgendeine vom Benutzer �bertragenen Variable in den PHP Code zu
- injizieren, k�nnen Sie die Anzahl "vergifteter" Variablen reduzieren,
- welche ein potentieller Angreifer zuf�gen k�nnte. Dieser ben�tigt mehr
- Zeit, um sich �bermittlungen auszudenken, und Ihre internen Variablen
- sind effektiv von den �bergebenen Benutzervariablen isoliert.
+ Ein Feature von PHP zur Erh�hung der Sicherheit ist die Konfiguration von
+ PHP mit <link linkend="ini.register-globals">register_globals</link> = off.
+ Mit Deaktivierung der M�glichkeit, irgendeine vom Benutzer �bertragenen
+ Variable in den PHP Code zu injizieren, k�nnen Sie die Anzahl "vergifteter"
+ Variablen reduzieren, welche ein potentieller Angreifer zuf�gen k�nnte.
+ Dieser ben�tigt mehr Zeit, um sich �bermittlungen auszudenken, und Ihre
+ internen Variablen sind effektiv von den �bergebenen Benutzervariablen
+ isoliert.
</para>
<para>
W�hrend dies den ben�tigten Aufwand mit PHP zu arbeiten leicht erh�ht
@@ -750,59 +806,6 @@
</para>
</sect1>
- <sect1 id="security.general">
- <title>Allgemeine �berlegungen</title>
- <simpara>
- Ein komplett sicheres System ist praktisch ein Ding der Unm�glichkeit,
- weshalb ein unter Sicherheitsprofis oft genutzter Ansatz ist, einen
- Mittelweg zwischen Risiko und Verwendbarkeit zu finden.
- Wenn jede von einem Benutzer �bermittelte Variable zwei Formen von
- biometrischer Pr�fung (wie z.B. ein Scan der Netzhaut und ein
- Fingerabdruck) verlangen w�rde, w�re eine extrem hohe Ebene der
- Verantwortlichkeit erreicht. Ein sehr komplexes Formular auszuf�llen
- w�rde auch eine halbe Stunde in Anspruch nehmen, was Benutzer dazu
- ermuntern k�nnte, Wege zur Umgehung der Sicherheitsma�nahmen zu suchen.
- </simpara>
- <simpara>
- Die beste Sicherheit ist oft unaufdringlich genug um den Anforderungen
- zu entsprechen, ohne den Benutzer an seiner Arbeit zu hindern oder den
- Code-Autor mit �bertriebener Komplexit�t zu �berlasten. Tats�chlich
- sind einige Sicherheitsangriffe nur die Folge von allzu strengen
- Sicherheitsma�nahmen, was mit der Zeit nur zu deren Unterminierung
- f�hrt.
- </simpara>
- <simpara>
- Eine Phrase die es wert ist, sich an sie zu erinnern: Ein System ist
- nur so gut wie das schw�chste Glied in der Kette. Wenn alle
- Transaktionen mittels Zeit, Ort, Transaktionstyp, etc. streng gelogged
- werden, der Benutzer aber nur mittels einem einzigen Cookie verifiziert
- wird, l�sst die Zuverl�ssigkeit f�r die Bindung des Benutzers an das
- Transaktions-Log bedrohlich nach.
- </simpara>
- <simpara>
- Denken Sie w�hrend der Tests daran, dass Sie selbst f�r die einfachsten
- Seiten nicht alle M�glichkeiten testen k�nnen. Der von Ihnen vielleicht
- erwartete Input wird zu dem eines verstimmten Mitarbeiters oder eines
- Crackers der Monate Zeit hat, oder einer Katze, die �ber die Tastatur
- l�uft in keinerlei Zusammenhang stehen. Deshalb betrachten Sie Ihren
- Code am Besten aus der logischen Perspektive um zu erkennen, wo
- unerwartete Daten eingebracht werden k�nnen und fragen sich dann,
- wie diese modifiziert, reduziert, oder weiter ausgef�hrt werden.
- </simpara>
- <simpara>
- Das Internet ist voll von Leuten welche versuchen, sich durch
- Entschl�sseln/zerst�ren Ihres Codes, den Zusammenbruch Ihres
- Systems, Einsetzen von unangebrachten Inhalten, und anderen, Ihren
- Tag interessant gestaltenden Ma�nahmen, einen Namen zu machen.
- Es ist egal, ob Sie eine kleine oder gro�e Site haben, Sie sind
- einfach ein Ziel wenn Sie online sind oder wenn Sie einen Server
- haben, zu dem man eine Verbindung aufbauen kann. Viele
- Cracker-Programme erkennen nicht die Gr��e, sondern durchsieben
- einfach gewaltige IP Bl�cke im Netz, um Opfer zu finden. Versuchen
- Sie, keines zu werden.
- </simpara>
- </sect1>
-
<sect1 id="security.current">
<title>Aktuell bleiben</title>
<simpara>
@@ -835,4 +838,7 @@
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
+vim600: syn=xml fen fdm=syntax fdl=2 si
+vim: et tw=78 syn=sgml
+vi: ts=1 sw=1
-->
