patch de/security
| From: | Karl Pflästerer | Date: | Sun, 13 Nov 2011 19:43:06 +0000 |
| Subject: | patch de/security | ||
| Groups: | php.doc.de | ||
| Request: | Send a blank email to doc-de+get-4012@lists.php.net to get a copy of this message | ||
Hallo,
hier ist ein Patch für
de/security/filesystem.xml
de/security/database.xml
de/security/variables.xml
Bei database.xml muss noch ein Bild kopiert werden; dies geht nicht als diff
<code>
svn cp https://svn.php.net/repository/phpdoc/en/trunk/security/figures
https://svn.php.net/repository/phpdoc/de/trunk/security
</code>
de/security/globals.xml müsste auch geändert werden; dort sind aber
auch große Unterschiede im Text, von denen ich nicht weiß, ob diese
absichtlich sind.
Jetzt auch mit Anhang
KP
Index: de/security/filesystem.xml =================================================================== --- de/security/filesystem.xml (revision 319118) +++ de/security/filesystem.xml (working copy) @@ -1,11 +1,11 @@ <?xml version="1.0" encoding="utf-8"?> <!-- $Revision$ --> -<!-- EN-Revision: 297028 Maintainer: hholzgra Status: ready --> +<!-- EN-Revision: 297645 Maintainer: hholzgra Status: ready --> <!-- Credits: tom --> <chapter xml:id="security.filesystem" xmlns="http://docbook.org/ns/docbook"> <title>Dateisystem - Sicherheit</title> <simpara> - PHP ist von den in den meisten Serversystemen implementierten + <acronym>PHP</acronym> ist von den in den meisten Serversystemen implementierten Sicherheitseinstellungen hinsichtlich der Berechtigungen auf Datei- und Verzeichnisebene abhängig. Dies verleiht Ihnen Kontrolle darüber, welche Dateien in dem Dateisystem gelesen werden dürfen. Vorsicht ist @@ -14,8 +14,8 @@ werden können. </simpara> <simpara> - Da PHP entwickelt wurde um Zugriffe auf das Dateisystem auf Benutzebene - zu erlauben, ist es natürlich auch möglich ein PHP Skript zu schreiben + Da <acronym>PHP</acronym> entwickelt wurde um Zugriffe auf das Dateisystem auf Benutzebene + zu erlauben, ist es natürlich auch möglich ein <acronym>PHP</acronym> Skript zu schreiben das Ihnen erlaubt Systemdateien wie /etc/passwd zu lesen, Ethernetverbindungen zu modifizieren, enorme Druckaufträge zu senden, etc. Dies hat offensichtliche Implikationen, indem Sie sicherstellen @@ -25,7 +25,7 @@ <simpara> Stellen Sie sich folgendes Skript vor, in dem ein User zum Ausdruck bringt, dass gerne eine Datei in seinem Heimatverzeichnis löschen - möchte. Dies geht von einer Situation aus, in der ein PHP Web-Interface + möchte. Dies geht von einer Situation aus, in der ein <acronym>PHP</acronym> Web-Interface regelmäßig zum Dateimanagement verwendet wird, und der Apache User ist auch berechtigt, in seinem Heimatverzeichnis Dateien zu löschen. </simpara> @@ -74,7 +74,7 @@ <itemizedlist> <listitem> <simpara> - Erteilen Sie dem PHP Web-user (Binärdatei) nur eingeschränkte Rechte. + Erteilen Sie dem <acronym>PHP</acronym> Web-user (Binärdatei) nur eingeschränkte Rechte. </simpara> </listitem> <listitem> @@ -149,7 +149,7 @@ <sect1 xml:id="security.filesystem.nullbytes"> <title>Probleme im Zusammenhang mit Nullbytes</title> <simpara> - Da PHP die Funktionen der C-Standardbibliothek für + Da <acronym>PHP</acronym> die Funktionen der C-Standardbibliothek für Dateisystemoperationen nutzt kann es Nullbytes in unerwarteter Weise verarbeiten. Da Nullbytes in C das Stringende festlegen werden Index: de/security/database.xml =================================================================== --- de/security/database.xml (revision 319118) +++ de/security/database.xml (working copy) @@ -1,8 +1,8 @@ <?xml version="1.0" encoding="utf-8"?> <!-- $Revision$ --> -<!-- EN-Revision: 297028 Maintainer: hholzgra Status: ready --> +<!-- EN-Revision: 313913 Maintainer: hholzgra Status: ready --> <!-- Credits: tom --> - <chapter xml:id="security.database" xmlns="http://docbook.org/ns/docbook"> + <chapter xml:id="security.database" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"> <title>Datenbank - Sicherheit</title> <simpara> @@ -21,9 +21,9 @@ Abfrage zu schaffen machen</link> kann. </simpara> <simpara> - Sie werden merken, dass PHP Ihre Datenbank alleine nicht schützen kann. + Sie werden merken, dass <acronym>PHP</acronym> Ihre Datenbank alleine nicht schützen kann. Die folgenden Abschnitte sind eine Einführung in die Grundlagen, wie man - innerhalb von PHP Skripten auf Datenbanken zugreift und diese manipuliert. + innerhalb von <acronym>PHP</acronym> Skripten auf Datenbanken zugreift und diese manipuliert. </simpara> <simpara> Denken Sie an diese einfache Regel: tief gestaffelte Verteidigung. Je mehr @@ -84,7 +84,7 @@ <!--simpara> If your database server has native SSL support, consider to use <link linkend="ref.openssl">OpenSSL functions</link> in communication between - PHP and database via SSL. + <acronym>PHP</acronym> and database via SSL. </simpara--> </sect1> @@ -92,12 +92,12 @@ <title>Verschlüsseltes Speichermodell</title> <simpara> SSL/SSH schützt zwar die gerade auf dem Weg befindlichen Daten vom Client - zum Server, jedoch nicht die dauernd in einer Datenbank gespeicherten - Daten. SSL ist ein "auf-der-Leitung" Protokoll. + zum Server: SSL/SSH schützt jedoch nicht die dauernd in einer + Datenbank gespeicherten Daten. SSL ist ein "auf-der-Leitung" Protokoll. </simpara> <simpara> Hat ein Angreifer direkten Zugriff auf Ihre Datenbank (den Webserver - umgehend), können die gespeicherten heiklen Daten aufgedeckt oder + umgehend), können gespeicherte heikle Daten aufgedeckt oder zweckentfremdet werden, außer wenn die Information von der Datenbank selbst geschützt ist. Die Daten zu verschlüsseln ist ein guter Weg, diese Gefahr zu mildern, doch bieten nur wenige Datenbanken diese Art der @@ -105,8 +105,8 @@ </simpara> <simpara> Der einfachste Weg, dieses Problem zu umgehen ist, erst einmal Ihr eigenes - Verschlüsselungspaket zu erstellen, und dieses dann in Ihren PHP Skripten - zu nutzen. PHP kann Ihnen in diesem Fall mit seinen verschiedenen + Verschlüsselungspaket zu erstellen, und dieses dann in Ihren <acronym>PHP</acronym> Skripten + zu nutzen. <acronym>PHP</acronym> kann Ihnen in diesem Fall mit seinen verschiedenen Erweiterungen helfen, wie z.B. <link linkend="ref.mcrypt">Mcrypt</link> and <link linkend="ref.mhash">Mhash</link>, welche eine große Auswahl an Verschlüsselungsalgorhythmen abdecken. Das Skript verschlüsselt die Daten @@ -116,7 +116,7 @@ <simpara> Im Fall von wirklich versteckten Daten, wenn deren unverfälschte Repräsentation nicht nötig ist (z.B. keine Anzeige), ist hashing ebenfalls - überlegenswert. Das bekannte Beispiel für das Hashing ist das Speichern des + überlegenswert. Das bekannte Beispiel für Hashing ist das Speichern des MD5 hash eines Passwortes in einer Datenbank, anstatt des Passwortes selbst. Siehe auch <function>crypt</function> und <function>md5</function>. </simpara> @@ -185,10 +185,10 @@ </programlisting> </example> Normale Benutzer klicken auf die 'nächste' bzw. 'vorige' Links, wo - <varname>$offset</varname> in der URL enthalten ist. Das Skript erwartet, + <varname>$offset</varname> in der <acronym>URL</acronym> enthalten ist. Das Skript erwartet, dass die ankommende <varname>$offset</varname> einen Dezimalwert enthält. Ganz gleich, jemand versucht einzubrechen, indem er das folgende in einer - <function>urlencode</function>'d Form an die URL anhängt + <function>urlencode</function>'d Form an die <acronym>URL</acronym> anhängt <informalexample> <programlisting> <![CDATA[ @@ -336,20 +336,34 @@ Weise genauso verwundbar sein. </para> </note> + <para> + <mediaobject> + <alt>Ein ausgearbeitetes Beispiel der Folgen von SQL Injection</alt> + <imageobject> + <imagedata fileref="de/security/figures/xkcd-bobby-tables.png" format="PNG"/> + </imageobject> + </mediaobject> + Bild mit freundlicher Genehmigung von <link xlink:href="&url.xkcd;327">xkcd</link> + </para> <sect2 xml:id="security.database.avoiding"> <title>Techniken zur Vermeidung</title> <simpara> - Sie könnten sich nun darauf berufen, dass der Angreifer in den meisten - Beispielen ein Stück Information über das Datenbankschema haben muss. Sie - haben recht, aber Sie wissen nie, wann und wie es genommen werden kann, - und wenn es passiert, kann Ihre Datenbank entblößt werden. Wenn Sie ein - Open Source, oder öffentlich verfügbares Paket zur Handhabung von - Datenbanken verwenden, welches vielleicht zu einem Content Management - System oder Forum gehört, können Eindringlinge leicht eine Kopie eines - Stücks Ihres Codes erstellen. Es kann auch ein Sicherheitsrisiko sein, - wenn es sich um ein schlecht designtes Paket handelt. + Obwohl es offensichtlich ist, dass ein Angreifer zumindest ein + wenig Kenntnis der genutzten Datenbankarchitektur besitzen muss, + um einen erfolgreichen Angriff durchzuführen, ist das Erlangen + dieser Informationen oft sehr einfach. Wenn die Datenbank zum + Beispiel Teil eines Open Source oder anderweitig öffentlich + verfügbaren Paketes mit einer Standard Installation ist, dann + ist diese Information vollkommen frei zugänglich. Diese + Information kann auch durch Closed Source Code - selbst wenn + dieser kodiert, verschleiert oder kompiliert ist - und sogar + durch ihren ureigenen Code durch die Anzeige von + Fehlermeldungen. Andere Methoden beinhalten die Nutzung + typischer Tabellen und Spalten Namen. Ein Login Formular etwa, + dass eine Tabelle 'users' mit den Spaltennamen 'id', 'username' + und 'password' nutzt. </simpara> <simpara> Diese Angriffe basieren hauptsächlich auf dem Ausnutzen des Codes, welcher @@ -371,7 +385,7 @@ <listitem> <simpara> Prüfen Sie, ob der gegebene Input dem erwarteten Datentyp entspricht. - PHP bietet eine große Auswahl an Funktionen zum Validieren des Input, + <acronym>PHP</acronym> bietet eine große Auswahl an Funktionen zum Validieren des Input, von den einfachsten unter <link linkend="ref.var">Variablenfunktionen</link> und <link linkend="ref.ctype">Character Type Functions</link> (z.B. Index: de/security/variables.xml =================================================================== --- de/security/variables.xml (revision 319118) +++ de/security/variables.xml (working copy) @@ -1,11 +1,11 @@ <?xml version="1.0" encoding="utf-8"?> <!-- $Revision$ --> -<!-- EN-Revision: 297028 Maintainer: hholzgra Status: ready --> +<!-- EN-Revision: 297645 Maintainer: hholzgra Status: ready --> <!-- Credits: tom --> <chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook"> <title>Vom Nutzer übermittelte Daten</title> <para> - In vielen PHP Programmen liegt die größte Schwäche nicht an der Sprache + In vielen <acronym>PHP</acronym> Programmen liegt die größte Schwäche nicht an der Sprache selbst, sondern bloß an Code, der nicht mit dem nötigen Augenmerk auf die Sicherheit geschrieben wurde. Deshalb sollten Sie sich immer Zeit nehmen, die Implikationen eines gegebenen Codestücks zu bedenken, um @@ -77,7 +77,7 @@ Sie könnten auch Überlegungen anstellen, ob Sie nicht register_globals, magic_quotes, oder andere bequeme Einstellungen abschalten, welche Sie in Punkto Gültigkeit, Herkunft, oder Inhalt einer gegebenen Variable - durcheinanderbringen könnten. Mit PHP im error_reporting(E_ALL) Modus + durcheinanderbringen könnten. Mit <acronym>PHP</acronym> im error_reporting(E_ALL) Modus zu arbeiten kann auch helfen, Sie vor Variablen zu warnen, welche benutzt werden, bevor sie geprüft oder initialisiert wurden (so können Sie verhindern, dass mit ungewöhnlichen Daten gearbeitet wird).
Index: de/security/filesystem.xml =================================================================== --- de/security/filesystem.xml (revision 319118) +++ de/security/filesystem.xml (working copy) @@ -1,11 +1,11 @@ <?xml version="1.0" encoding="utf-8"?> <!-- $Revision$ --> -<!-- EN-Revision: 297028 Maintainer: hholzgra Status: ready --> +<!-- EN-Revision: 297645 Maintainer: hholzgra Status: ready --> <!-- Credits: tom --> <chapter xml:id="security.filesystem" xmlns="http://docbook.org/ns/docbook"> <title>Dateisystem - Sicherheit</title> <simpara> - PHP ist von den in den meisten Serversystemen implementierten + <acronym>PHP</acronym> ist von den in den meisten Serversystemen implementierten Sicherheitseinstellungen hinsichtlich der Berechtigungen auf Datei- und Verzeichnisebene abhängig. Dies verleiht Ihnen Kontrolle darüber, welche Dateien in dem Dateisystem gelesen werden dürfen. Vorsicht ist @@ -14,8 +14,8 @@ werden können. </simpara> <simpara> - Da PHP entwickelt wurde um Zugriffe auf das Dateisystem auf Benutzebene - zu erlauben, ist es natürlich auch möglich ein PHP Skript zu schreiben + Da <acronym>PHP</acronym> entwickelt wurde um Zugriffe auf das Dateisystem auf Benutzebene + zu erlauben, ist es natürlich auch möglich ein <acronym>PHP</acronym> Skript zu schreiben das Ihnen erlaubt Systemdateien wie /etc/passwd zu lesen, Ethernetverbindungen zu modifizieren, enorme Druckaufträge zu senden, etc. Dies hat offensichtliche Implikationen, indem Sie sicherstellen @@ -25,7 +25,7 @@ <simpara> Stellen Sie sich folgendes Skript vor, in dem ein User zum Ausdruck bringt, dass gerne eine Datei in seinem Heimatverzeichnis löschen - möchte. Dies geht von einer Situation aus, in der ein PHP Web-Interface + möchte. Dies geht von einer Situation aus, in der ein <acronym>PHP</acronym> Web-Interface regelmäßig zum Dateimanagement verwendet wird, und der Apache User ist auch berechtigt, in seinem Heimatverzeichnis Dateien zu löschen. </simpara> @@ -74,7 +74,7 @@ <itemizedlist> <listitem> <simpara> - Erteilen Sie dem PHP Web-user (Binärdatei) nur eingeschränkte Rechte. + Erteilen Sie dem <acronym>PHP</acronym> Web-user (Binärdatei) nur eingeschränkte Rechte. </simpara> </listitem> <listitem> @@ -149,7 +149,7 @@ <sect1 xml:id="security.filesystem.nullbytes"> <title>Probleme im Zusammenhang mit Nullbytes</title> <simpara> - Da PHP die Funktionen der C-Standardbibliothek für + Da <acronym>PHP</acronym> die Funktionen der C-Standardbibliothek für Dateisystemoperationen nutzt kann es Nullbytes in unerwarteter Weise verarbeiten. Da Nullbytes in C das Stringende festlegen werden Index: de/security/database.xml =================================================================== --- de/security/database.xml (revision 319118) +++ de/security/database.xml (working copy) @@ -1,8 +1,8 @@ <?xml version="1.0" encoding="utf-8"?> <!-- $Revision$ --> -<!-- EN-Revision: 297028 Maintainer: hholzgra Status: ready --> +<!-- EN-Revision: 313913 Maintainer: hholzgra Status: ready --> <!-- Credits: tom --> - <chapter xml:id="security.database" xmlns="http://docbook.org/ns/docbook"> + <chapter xml:id="security.database" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"> <title>Datenbank - Sicherheit</title> <simpara> @@ -21,9 +21,9 @@ Abfrage zu schaffen machen</link> kann. </simpara> <simpara> - Sie werden merken, dass PHP Ihre Datenbank alleine nicht schützen kann. + Sie werden merken, dass <acronym>PHP</acronym> Ihre Datenbank alleine nicht schützen kann. Die folgenden Abschnitte sind eine Einführung in die Grundlagen, wie man - innerhalb von PHP Skripten auf Datenbanken zugreift und diese manipuliert. + innerhalb von <acronym>PHP</acronym> Skripten auf Datenbanken zugreift und diese manipuliert. </simpara> <simpara> Denken Sie an diese einfache Regel: tief gestaffelte Verteidigung. Je mehr @@ -84,7 +84,7 @@ <!--simpara> If your database server has native SSL support, consider to use <link linkend="ref.openssl">OpenSSL functions</link> in communication between - PHP and database via SSL. + <acronym>PHP</acronym> and database via SSL. </simpara--> </sect1> @@ -92,12 +92,12 @@ <title>Verschlüsseltes Speichermodell</title> <simpara> SSL/SSH schützt zwar die gerade auf dem Weg befindlichen Daten vom Client - zum Server, jedoch nicht die dauernd in einer Datenbank gespeicherten - Daten. SSL ist ein "auf-der-Leitung" Protokoll. + zum Server: SSL/SSH schützt jedoch nicht die dauernd in einer + Datenbank gespeicherten Daten. SSL ist ein "auf-der-Leitung" Protokoll. </simpara> <simpara> Hat ein Angreifer direkten Zugriff auf Ihre Datenbank (den Webserver - umgehend), können die gespeicherten heiklen Daten aufgedeckt oder + umgehend), können gespeicherte heikle Daten aufgedeckt oder zweckentfremdet werden, außer wenn die Information von der Datenbank selbst geschützt ist. Die Daten zu verschlüsseln ist ein guter Weg, diese Gefahr zu mildern, doch bieten nur wenige Datenbanken diese Art der @@ -105,8 +105,8 @@ </simpara> <simpara> Der einfachste Weg, dieses Problem zu umgehen ist, erst einmal Ihr eigenes - Verschlüsselungspaket zu erstellen, und dieses dann in Ihren PHP Skripten - zu nutzen. PHP kann Ihnen in diesem Fall mit seinen verschiedenen + Verschlüsselungspaket zu erstellen, und dieses dann in Ihren <acronym>PHP</acronym> Skripten + zu nutzen. <acronym>PHP</acronym> kann Ihnen in diesem Fall mit seinen verschiedenen Erweiterungen helfen, wie z.B. <link linkend="ref.mcrypt">Mcrypt</link> and <link linkend="ref.mhash">Mhash</link>, welche eine große Auswahl an Verschlüsselungsalgorhythmen abdecken. Das Skript verschlüsselt die Daten @@ -116,7 +116,7 @@ <simpara> Im Fall von wirklich versteckten Daten, wenn deren unverfälschte Repräsentation nicht nötig ist (z.B. keine Anzeige), ist hashing ebenfalls - überlegenswert. Das bekannte Beispiel für das Hashing ist das Speichern des + überlegenswert. Das bekannte Beispiel für Hashing ist das Speichern des MD5 hash eines Passwortes in einer Datenbank, anstatt des Passwortes selbst. Siehe auch <function>crypt</function> und <function>md5</function>. </simpara> @@ -185,10 +185,10 @@ </programlisting> </example> Normale Benutzer klicken auf die 'nächste' bzw. 'vorige' Links, wo - <varname>$offset</varname> in der URL enthalten ist. Das Skript erwartet, + <varname>$offset</varname> in der <acronym>URL</acronym> enthalten ist. Das Skript erwartet, dass die ankommende <varname>$offset</varname> einen Dezimalwert enthält. Ganz gleich, jemand versucht einzubrechen, indem er das folgende in einer - <function>urlencode</function>'d Form an die URL anhängt + <function>urlencode</function>'d Form an die <acronym>URL</acronym> anhängt <informalexample> <programlisting> <![CDATA[ @@ -336,20 +336,34 @@ Weise genauso verwundbar sein. </para> </note> + <para> + <mediaobject> + <alt>Ein ausgearbeitetes Beispiel der Folgen von SQL Injection</alt> + <imageobject> + <imagedata fileref="de/security/figures/xkcd-bobby-tables.png" format="PNG"/> + </imageobject> + </mediaobject> + Bild mit freundlicher Genehmigung von <link xlink:href="&url.xkcd;327">xkcd</link> + </para> <sect2 xml:id="security.database.avoiding"> <title>Techniken zur Vermeidung</title> <simpara> - Sie könnten sich nun darauf berufen, dass der Angreifer in den meisten - Beispielen ein Stück Information über das Datenbankschema haben muss. Sie - haben recht, aber Sie wissen nie, wann und wie es genommen werden kann, - und wenn es passiert, kann Ihre Datenbank entblößt werden. Wenn Sie ein - Open Source, oder öffentlich verfügbares Paket zur Handhabung von - Datenbanken verwenden, welches vielleicht zu einem Content Management - System oder Forum gehört, können Eindringlinge leicht eine Kopie eines - Stücks Ihres Codes erstellen. Es kann auch ein Sicherheitsrisiko sein, - wenn es sich um ein schlecht designtes Paket handelt. + Obwohl es offensichtlich ist, dass ein Angreifer zumindest ein + wenig Kenntnis der genutzten Datenbankarchitektur besitzen muss, + um einen erfolgreichen Angriff durchzuführen, ist das Erlangen + dieser Informationen oft sehr einfach. Wenn die Datenbank zum + Beispiel Teil eines Open Source oder anderweitig öffentlich + verfügbaren Paketes mit einer Standard Installation ist, dann + ist diese Information vollkommen frei zugänglich. Diese + Information kann auch durch Closed Source Code - selbst wenn + dieser kodiert, verschleiert oder kompiliert ist - und sogar + durch ihren ureigenen Code durch die Anzeige von + Fehlermeldungen. Andere Methoden beinhalten die Nutzung + typischer Tabellen und Spalten Namen. Ein Login Formular etwa, + dass eine Tabelle 'users' mit den Spaltennamen 'id', 'username' + und 'password' nutzt. </simpara> <simpara> Diese Angriffe basieren hauptsächlich auf dem Ausnutzen des Codes, welcher @@ -371,7 +385,7 @@ <listitem> <simpara> Prüfen Sie, ob der gegebene Input dem erwarteten Datentyp entspricht. - PHP bietet eine große Auswahl an Funktionen zum Validieren des Input, + <acronym>PHP</acronym> bietet eine große Auswahl an Funktionen zum Validieren des Input, von den einfachsten unter <link linkend="ref.var">Variablenfunktionen</link> und <link linkend="ref.ctype">Character Type Functions</link> (z.B. Index: de/security/variables.xml =================================================================== --- de/security/variables.xml (revision 319118) +++ de/security/variables.xml (working copy) @@ -1,11 +1,11 @@ <?xml version="1.0" encoding="utf-8"?> <!-- $Revision$ --> -<!-- EN-Revision: 297028 Maintainer: hholzgra Status: ready --> +<!-- EN-Revision: 297645 Maintainer: hholzgra Status: ready --> <!-- Credits: tom --> <chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook"> <title>Vom Nutzer übermittelte Daten</title> <para> - In vielen PHP Programmen liegt die größte Schwäche nicht an der Sprache + In vielen <acronym>PHP</acronym> Programmen liegt die größte Schwäche nicht an der Sprache selbst, sondern bloß an Code, der nicht mit dem nötigen Augenmerk auf die Sicherheit geschrieben wurde. Deshalb sollten Sie sich immer Zeit nehmen, die Implikationen eines gegebenen Codestücks zu bedenken, um @@ -77,7 +77,7 @@ Sie könnten auch Überlegungen anstellen, ob Sie nicht register_globals, magic_quotes, oder andere bequeme Einstellungen abschalten, welche Sie in Punkto Gültigkeit, Herkunft, oder Inhalt einer gegebenen Variable - durcheinanderbringen könnten. Mit PHP im error_reporting(E_ALL) Modus + durcheinanderbringen könnten. Mit <acronym>PHP</acronym> im error_reporting(E_ALL) Modus zu arbeiten kann auch helfen, Sie vor Variablen zu warnen, welche benutzt werden, bevor sie geprüft oder initialisiert wurden (so können Sie verhindern, dass mit ungewöhnlichen Daten gearbeitet wird).