Sicheres PHP-Programmieren für Einsteiger von Ulrich Günther, Autor von PHP - Ein praktischer Einstieg

Mit PHP und anderen WWW-Skriptspachen läßt sich umfangreiche Funktionalität über das WWW anbieten. Damit diese Funktionalität nicht von Dritten zu Ihrem Schaden oder zum Schaden anderer eingesetzt werden kann, ist es wichtig, Sicherheitslücken von vornherein zu vermeiden. Das Vermeiden von typischen "Anfängerfehlern" ist dabei ein wichtiger Schritt. Dieser Artikel zeigt Ihnen eine Reihe typischer Fallen. Sie lernen außerdem, wie Sie diese und ähnliche Szenarien bereits im voraus erkennen und vermeiden können. Zum Schluß gibt es Strategietips, wie Sie Ihre Site absichern und so sicher wie möglich gestalten können.

Sie haben es bestimmt schon einmal in den Medien gelesen oder gehört: Da ist mal wieder in den Webserver einer großen Firma, Organisation oder Regierungsbehörde eingebrochen worden, und die unbekannten Hacker (auch "Cracker" genannt) haben die Webseiten verunstaltet oder gar schlimmeren Schaden angerichtet. Dieses sind die spektakuläreren Fälle. Leider kommen Einbrüche in Webserver recht häufig vor – in vielen Fällen merken die Opfer auch gar nichts davon. Einige Beispiele zur Illustration:

• An einer Universität dringen Studenten über eine Webseite zum Abfragen von Examensergebnissen in die Datenbank ihres Dozenten ein und ändern dort ihre Noten.
• Über ein "Loch" in einem Webskript erhalten Unbefugte einen Verzeichnisauszug eines Webservers einer großen Firma und besorgen sich Insiderinformationen, die dort ungelinkt abgespeichert sind und erst am nächsten Tag bekannt gemacht werden sollen. Durch den rechtzeitigen Kauf oder Verkauf eines Aktienpakets verschaffen sich die Eindringlinge einen illegalen Gewinn.
• Eine ungenügend gesicherte Website eines Online-Versandgeschäfts gibt durch SQL-Codeinjektion vertrauliche Kreditkartendaten der Kunden an Unbefugte preis, die anschließend zum Aufladen von Prepay-Handys verwendet werden.
• Eine Website, die Benutzern das Heraufladen von Fotodateien in ein persönliches "Album" ermöglicht, wird von einem böswilligen Zeitgenossen mit einem Skript statt einer Fotodatei beschickt. Damit besorgt der Schurke sich die Paßwortdatei des Servers und verschafft sich so Zugang zu der Maschine. Damit kann er dann Software installieren, mit der sich Junkmail versenden läßt.

Die Schadensmöglichkeiten sind hier nahezu unbegrenzt. Was nicht unbegrenzt ist, sind aber die grundlegenden Techniken, mit denen sich böswillige Hacker Zugang zu Ihrem Webserver oder Ihrer Datenbank verschaffen können.

Was Computerprogramme dürfen – und was nicht

Okay, nun sind Sie vielleicht gerade dabei, Ihre ersten zaghaften Schritte in das spannende Reich der PHP-Programmierung zu unternehmen. Und ich Brummbär erzähle Ihnen jetzt schon, was dabei alles schiefgehen kann. Sollten Sie die PHP-Programmierung nicht doch besser einem ausgebildeten Informatiker überlassen? Nun mal keine Panik – was Sie hier zu lesen bekommen, ist nützlich, leicht verdaulich und Ihrem Feld-Wald-und-Wiesen-Programmierer vielleicht auch neu.

Auf die Gefahr hin, jetzt eventuell meine Kollegen madig zu machen: Die meisten Sicherheitslücken in Websites gehen vermutlich auf das Konto von erfahrenen Programmierern. Denen gegenüber haben Sie als Anfänger einen Vorteil: Sie sind noch nicht betriebsblind. Wie meine ich das?

Ganz einfach: Die weitaus meisten Programmierer (auch die, die erst in den letzten paar Jahren ausgebildet wurden) sind noch darauf gedrillt, Computerprogramme "zum Laufen" zu bringen. Früher, als Computer noch mutterseelenallein vor sich hin wurschtelten, war vor allem eins wichtig: Ein Programm mußte auf eine legale Eingabe hin so schnell und speicherplatzschonend wie möglich eine brauchbare Ausgabe liefern.

Zugegeben, es wäre schon etwas absurd gewesen, wenn ein Benutzer eines DOS-PCs einem Programm absichtlich Datensalat vorgesetzt hätte, um es zur Herausgabe oder Modifizierung von Daten zu zwingen, die ohnehin unter seiner Kontrolle standen. Die wenigsten Leute brechen bei sich zu Hause ein. Wenn Ihr Haus für Einbrecher nicht zu erreichen ist, darf auch ruhig ein Fenster offenstehen. Mit anderen Worten, Ihr Standalone-Computerprogramm durfte bei abstrusen Eingaben ggf. auch Dinge machen, für die es nicht vorgesehen war.

Seit es das Internet gibt, sieht das allerdings etwas anders aus. Plötzlich kann die ganze Welt Daten in beliebiger Kombination an Ihren Rechner schicken. Wenn diese Daten zu einem Ihrer Programme gelangen (zum Beispiel einem PHP-Skript), sollte sichergestellt sein, daß das Programm damit nur Operationen unternimmt, mit denen Sie auch einverstanden sind. Wenn die Daten nicht Ihren Vorstellungen entsprechen, dann sollte Ihr Programm wenigstens sicher damit umgehen. Das könnte z.B. durch die Ausgabe einer Fehlermeldung oder einen entsprechenden Logeintrag geschehen oder auch einfach durch einen kalten Verbindungsabbruch mit dem Störenfried, der Ihnen den Müll ins Haus geschickt hat. Wir halten also fest: Ein Internetprogramm muß nicht nur das machen, wozu es vorgesehen ist, sondern darf auch nichts machen, wozu es nicht vorgesehen ist.

Hört sich einleuchtend an? Prima. Wenn Sie den ersten Teil dieser Regel schon etwas kompliziert finden, dann hört sich der zweite Teil vielleicht nach einer zusätzlichen Belastung an. Ist es aber nicht unbedingt. Der erste Teil wird nämlich einfacher, wenn Sie genau festlegen, was Ihr Programm unter welchen Umständen machen darf. Mit anderen Worten: Mit den Sicherheitslücken verschwinden oft auch die Bugs.

Ein einfaches Beispiel zur Illustration

Sie haben eine Webseite mit einem Formular, in dem sich eine Auswahlliste befindet. Über diese Liste können Ihre Benutzer einen Monat auswählen, also eine Zahl zwischen 1 und 12. Beim Abschicken des Formulars wird diese Zahl an Ihr Skript übergeben ... Halt!

Warum habe ich jetzt so laut: "Halt!" geschrien? Weil das eben der von uns erwartete Ablauf ist: Ein Benutzer füllt unser Formular aus und schickt es an unser Skript. Soweit, so gut. So soll es sein. Wie steht es mit dem Unvor(her)gesehenen?

Sehen wir uns einmal das <form>-Tag Ihres Formulars an.

...
<form method="post" action="meinSkript.php">
...

Das besagt, daß Ihr Formular beim Abschicken an ein Skript namens meinSkript.php geschickt wird, das sich im selben Verzeichnis auf Ihrem Webserver befindet wie das gerade angezeigte Formular. Na ja, aber was hält uns davon ab, das Tag so zu schreiben:

...
<form method="post" action="http://www.hacking-ziel.de/seinSkript.php">
...

Damit werden die Daten an ein anderes Skript im Internet geschickt. Jetzt fragen Sie sich natürlich, warum Sie Ihre mühsam eingesammelten Daten an jemand anderen schicken sollen, der damit vermutlich gar nichts anfangen kann. Die Frage ist berechtigt. Sie können sie sich gleich selbst beantworten. Lassen Sie mich mit einer Gegenfrage weitermachen: Wenn wir unsere Daten an Skripte von anderen Leuten schicken können, was hält dann andere Leute davon ab, Formulare zu schreiben, mit denen sie Daten an unser Skript meinSkript.php schicken können?

Die Antwort: gar nichts. Und darin liegt das Problem: Wir können damit nämlich nicht mehr so einfach davon ausgehen, daß die Daten, die unter dem Namen der Auswahlliste an unser Skript übergeben werden, auch tatsächlich von der Liste stammen. Wenn ein Hacker das so will, können das beliebige Daten sein. Mit anderen Worten: Neben Nummern muß unser Skript meinSkript.php auch mit beliebigen anderen Zeichenketten fertig werden können.

Ganz allgemein ausgedrückt: Egal, ob Ihr Formularelement eine Auswahlliste, eine Checkbox, ein Texteingabefeld oder ein Radiobutton ist – das Skript, an das das Formular geschickt wird, bekommt für jedes Element nur den (frei wählbaren) Namen des Elements und den dazugehörigen Wert. Der kann immer eine beliebige Zeichenkette sein.

Wie kann ein Hacker das ausnutzen? Drei Beispiele

Um Ihr Skript mit speziell konstruierten Formulardaten zu einer Art "Zombie" werden zu lassen, muß der Hacker eine bereits in Ihrem Skript vorhandene Funktionalität ausnutzen, z.B.:

• einen vorhandenen Befehl, der auf Dateien zugreift. Ein solcher Befehl kann ggf. dazu verwendet werden, Skriptdateien des Hackers auf den Server zu legen – beispielsweise PHP-Skripte, die dann über das Web aufgerufen und ausgeführt werden können.
• einen vorhandenen Befehl, der auf die Kommandoebene (auch "DOS-Fenster", "Shell" oder "Kommandozeile") des Webservers zugreift. Damit lassen sich ggf. Dateien anlegen, löschen, überschreiben, per E-Mail versenden, kopieren, Logins anlegen, Passwörter ändern – je nachdem, was der Webserver auf dem Rechner darf.
• eine vorhandene Datenbankabfrage, in die zusätzlicher Code eingefügt wird. Damit lassen sich ggf. Datenbanken verändern oder auslesen oder Datenbankeinträge vortäuschen.

Sehen wir uns dafür ein paar Beispiele an:

Beispiel 1: Unerlaubter Zugriff auf Dateien

Sehen wir uns das einmal anhand eines kleinen Grußkartenskripts an. Ich gebe Ihnen ein kleines HTML-Formular mit den folgenden Eingabeelementen:

...
<form method="post" action="meinGrussSkript.php">
<p>
Geben Sie hier Ihren Vornamen ein:
<input type="text" name="absender">
</p>
<p>
Geben Sie hier die E-Mail-Adresse der Person ein, die Sie grüßen wollen:
<input type="text" name="adressat">
</p>
<p>
Geben Sie hier die Grußbotschaft ein:
<textarea rows="10" cols="60" name="botschaft">
</p>
<p>
<input type="submit" value="Gruss absenden">
</p>
</form>
...

Den Rest des HTML-Codes habe ich der Übersichtlichkeit wegen weggelassen. Wenn Sie die Seite in Ihren Browser laden, sehen Sie ein Texteingabefeld für Ihren Vornamen, eines für die E-Mail-Adresse des Adressaten (damit er oder sie per E-Mail benachrichtigt werden kann) sowie ein Feld, in das Sie die eigentliche Botschaft eingeben können. Außerdem sehen Sie einen Button, mit dem Sie Ihre elektronische Postkarte abschicken können. Einfach, nicht?

Bisher haben wir auch noch nichts falsch gemacht. Sehen wir uns jetzt Auszüge des dazugehörigen PHP-Skripts meinGrussSkript.php an:

...
// Abspeichern der Grußbotschaft als HTML-Datei in einem Unterverzeichnis
// "gruesse" unserer Website. Als Dateiname dient der Vorname des Absenders,
// der uns in $_POST["absender"] vom Browser übergeben wird.
// Zuerst öffnen wir die Datei:
$fp = fopen ("/pfad/zur/site/gruesse/".$_POST["absender"].".html", "w");
// Dann verpacken wir die Botschaft in etwas HTML ...
$botschaft="<html><body>".$_POST["botschaft"]."</body></html>";
// ... und schreiben sie in die Datei:
fwrite($fp,$botschaft);
// Anschließend schicken wir eine E-Mail an den Adressaten, um ihn von der
// Grußbotschaft zu unterrichten. In diese E-Mail schreiben wir eine URL, die
// auf unsere eben geschriebene Datei (die Grußpostkarte) zeigt.
// Nach der E-Mail geben wir noch eine Bestätigung an den Absender aus.
...

Hier haben wir wieder viel weggelassen und konzentrieren uns statt dessen auf die Punkte, an denen der Hase begraben liegt. Wie können wir dieses Skript dazu bewegen, etwas vom Eigentümer Unvorhergesehenes zu tun? Nun, lassen Sie uns einen Plan schmieden: Die Site wird vermutlich eine Startseite haben. Ihrem Browser können Sie entnehmen, wie die entsprechende Datei heißt, z.B. index.html. Einem "echten" Kartengruß können Sie entnehmen, daß index.html in dem Verzeichnis über dem liegt, in dem die Grußdateien gespeichert werden. Dazu brauchen Sie nur die URL der Startseite und die der Grußkarte (in der E-Mail) zu vergleichen. Okay, dann überlegen Sie sich einmal, was passiert, wenn der Benutzer

../index

als Absendernamen eingibt. Haben Sie's erraten? Die Datei, die wir jetzt zum Schreiben öffnen, ist die Datei mit dem Pfad:

/pfad/zur/site/gruesse/../index.html

Das ist aber nichts anderes als:

/pfad/zur/site/index.html

Damit haben wir es geschafft, die Startseite zu überschreiben, und zwar mit dem von uns durch das Texteingabefeld vorgegebenen Inhalt. Wie hätten wir das hier verhindern können? Ganz einfach: Wir hätten dafür sorgen können, daß alle Sonderzeichen aus dem Absendernamen gefiltert werden, bevor er als Dateiname verwendet wird. Noch besser, wir hätten uns einen eigenen Dateinamen erzeugen können, etwa so:

...
$dateiname = "/pfad/zur/site/gruesse/".uniqid("").".html";
$fp = fopen ($dateiname, "w");
...

Hier wäre es also angebracht gewesen, sich genau zu überlegen, was in unserer Variablen $_POST["absender"] stehen könnte und wie es dann verwendet wird. Im Prinzip ist es nie eine gute Idee, vom Browser stammende Variablen in Dateinamen oder in externen Befehlen (Befehle, die über die Kommandozeile des Servers oder der Datenbank aufgerufen werden) zu verwenden. In den meisten Fällen ist das auch nicht notwendig. Das nächste Beispiel zeigt, wie ein externer Befehl mißbraucht werden kann.

Beispiel 2: Code-Injektion in die Kommandozeile

Die zweite "Technik", vor der ich Sie hier warnen möchte, läuft ebenfalls nach diesem Strickmuster ab, ist aber potentiell noch gefährlicher. Hier mischen wir unseren Eingabedaten nicht nur Teile von Dateinamen bei, sondern führen sogar Kommandos auf dem Server aus. Das Szenario: Sie haben ein Kommandozeilenprogramm namens horoskop geschrieben/gekauft/geliehen/geklaut, das ein Horoskop ausgibt, wenn Sie ihm ein Datum als Kommandozeilenparameter übergeben. Unter Windows ginge das für den 7. Oktober 2002 so:

C:\Programme\SuperHoroskop>horoskop.exe 7 10 2002
Nicht alle Tage sind so ereignisreich wie der heutige, ...

Die Ausgabe dieses Programms wollen Sie nun über das Web zugänglich machen. Also schreiben Sie ein Formular, in dem die Benutzer über drei Auswahllisten Tag, Monat und Jahr wählen können. Die Listen haben jeweils die Namen "tag", "monat" und "jahr". Da Sie ja schon wissen, daß es nicht unbedingt Auswahllisten sein müssen und ein Hacker sich genausogut ein beliebiges Formular zum Hacken zusammenbasteln kann, lassen wir das Formular links liegen und fangen gleich mit dem Scriptus delicti an:

...
$tag=$_POST["tag"]; $monat=$_POST["monat"]; $jahr=$_POST["jahr"];
system("C:\Programme\SuperHoroskop>horoskop.exe $tag $monat $jahr");
...

Wieder einmal funktioniert unser Skript blendend. Wenn Sie das dafür vorgesehene Formular verwenden, bekommen Sie Ihr Horoskop. Wenn Sie aber ein Formular mit dem folgenden versteckten Eingabefeld verwenden:

...
<input type="hidden" name="tag" value="11 9 2001; del c:\*.*;">
...

dann bleibt von dem Dateisystem des Servers so gut wie nichts übrig. Die erste ungeschützte Variable reicht, um nicht nur alle zur erfolgreichen Ausführung von horoskop.exe notwendigen Parameter zu übergeben, sondern auch, um ein Semikolon als Trennzeichen und einen nachfolgenden DELETE-Befehl zu "injizieren". Den Rest der Variablen können wir leer lassen (oder mit anderen Befehlen füllen). Um sich gegen derartige Hackerangriffe zu schützen, brauchen Sie aber keine Armee. Sie hätten hier auch einfach sicherstellen können, daß sich in Ihren Variablen nur Zahlen befinden, die jeweils einen Tag, Monat oder ein Jahr darstellen. Bei anderen Daten hätten Sie Ihr Skript mit einer Fehlermeldung abbrechen können. Alternativ dazu gibt es auch die PHP-Funktion escapeshellarg(), die alle potentiell gefährlichen Zeichen durch Rückwärtsstriche entschärft und die Parameter in Anführungsstriche setzt:

...
$tag=escapeshellarg($_POST["tag"]);
$monat=escapeshellarg($_POST["monat"]);
$jahr=escapeshellarg($_POST["jahr"]);
...

Damit muß aber horoskop.exe auch mit evtl. komischen Parametern fertig werden, was u.U. immer noch ein Sicherheitsrisiko darstellt. Eine Eingabeüberprüfung wäre hier definitiv besser.

Beispiel 3: SQL-Codeinjektion

Der dritte Trick, den ich Ihnen hier vorstellen möchte, ist wieder eine Variante der beiden vorherigen Sicherheitslücken. In diesem Fall nutzen wir die PHP-Schnittstelle zu unserer Datenbank aus, um uns Zutritt zu einem System zu verschaffen. Nehmen wir einmal an, daß Sie die Zugangsdaten zu einer Internetbank in einer Tabelle namens Kontos in Ihrer Datenbank speichern. Die Tabelle hat zwei Spalten, und in jeder Zeile finden wir die Daten für ein Konto:

Auf eine solche Tabelle können Sie in vielen Datenbanken über eine Sprache namens SQL zugreifen (vielleicht kennen Sie SQL ja auch schon?). Ein SQL-Befehl, mit dem wir uns z.B. den Eintrag für das Konto mit der Nummer 873221 und dem Passwort abcd1234 heraussuchen können, sieht so aus:

select * from Kontos where KontoNummer = 873221 and KontoPasswort = "abcd1234"

Wenn Sie Ihren Benutzern jetzt eine Login-Seite vorsetzen, mit denen diese sich bei Ihrem System durch Kontonummer und Passwort identifizieren können, können Sie in Ihrem PHP-Skript den SQL-Befehl wie folgt zusammensetzen:

...
$sqlBefehl = "select * from Konto where KontoNummer = "
           . $_POST["kontonummer"]
           . " and KontoPasswort = \""
           . $_POST["kontopasswort"]."\"";
...

Für die Kontonummer 873221 und das Passwort abcd1234 bekommen Sie so den gleichen SQL-Befehl wie oben, aber dafür hübsch in eine PHP-Zeichenkette (String) verpackt. Das ist dann sehr mundgerecht für die diversen Query-Funktionen in PHP, die Ihre Befehle an die gewünschte Datenbank schicken.

Ein derartiges Skript können Sie evtl. auch ohne spezielles Formular hacken. Um sich als Unbefugter Zugang zu dem Konto mit – sagen wir mal – der Nummer 548745 zu verschaffen, können Sie das Passwortfeld gleich ganz leer lassen. Dafür geben Sie als Kontonummer den folgenden String ein:

548745 or KontoNummer = 0 

Dann sieht Ihr SQL-Befehl so aus:

select * from Kontos where KontoNummer = 548745 or KontoNummer = 0 and KontoPasswort = ""

Mit anderen Worten: Die Datenbank gibt Ihnen alle Einträge, bei denen mindestens eine von zwei Bedingungen zutrifft:

1. Die Kontonummer ist 548745.
2. Die Kontonummer ist 0, und das Kontopasswort ist leer (hier könnten wir statt "0" natürlich auch eine beliebige andere Dummy-Kontonummer angeben).

Die zweite Bedingung ist wahrscheinlich nicht zu erfüllen, aber die erste ist trivial, jedenfalls solange das Konto mit der Nummer 548745 existiert. Wie auch immer, wir können jetzt frei über das Konto verfügen. Mit ähnlichen Tricks lassen sich ggf. auch Kontostände ändern, Transaktionen vortäuschen, Kontos einrichten etc.

Übrigens waren wir hier noch gnädig – bei einigen Datenbanken hätten wir auch

548745;
delete from Kontos where KontoNummer = 643894;
select * from Kontos where KontoNummer =

eingeben können und uns nicht nur illegal Zugriff auf ein fremdes Konto, sondern auch unserem Boss (dessen Gehaltskonto Nummer 643894 wir uns irgendwie besorgt haben) zur spurlosen Pleite verhelfen können.

Der letztere Trick läßt sich leicht unterbinden, wenn Sie den Vergleichswert in Ihrem SQL-Befehl in Anführungszeichen packen, also:

...
$sqlBefehl = "select * from Konto where KontoNummer = \""
           . $_POST["kontonummer"]
           . "\" and KontoPasswort = \""
           . $_POST["kontopasswort"]."\"";
...

Damit würde dann unsere bösartige Eingabe tatsächlich als (nicht existente) Kontonummer aufgefaßt. Wenn Sie das für ein bißchen naiv halten, dann haben Sie da nicht ganz unrecht. Erstens: Können wir denn jede Zahl so einfach als String behandeln? Zweitens: Was hält einen Hacker davon ab, selbst Anführungszeichen einzugeben und so unsere Sicherheitsmaßnahme zu unterlaufen? Gute Fragen.

Die Antwort auf die erste Frage ist: "Nicht immer, aber oft." Wenn der übergebene Wert eine Zahl sein muß, z.B. in einem Größenvergleich, dann müssen wir vorher explizit überprüfen, ob es sich auch tatsächlich um eine Zahl handelt.

Die Antwort auf die zweite Frage hängt von Ihrer PHP-Konfiguration ab. Entscheidend ist hier ein Konfigurationsparameter namens magic_quotes_gpc in der Konfigurationsdatei php.ini. Er bestimmt, ob vom Browser übergebene Anführungsstriche (einzelne oder doppelte) mit einem vorangestellten Rückwärtsstrich versehen werden sollen oder nicht. Was bedeutet das? Ganz einfach: Stellen Sie sich vor, daß Sie ein Formular mit einem Texteingabefeld namens "gericht" haben, in das die Namen von Speisen eingegeben werden sollen. Das verarbeitende Skript könnte im einfachsten Fall einfach den angegebenen Namen wieder anzeigen:

...
echo $_POST["gericht"];
...

Wenn Sie magic_quotes_gpc in php.ini auf On gesetzt haben, wird Ihnen bei der Eingabe

Forelle nach "Hausfrauen-Art" mit Sahnesoße

nicht das Original, sondern

Forelle nach \"Hausfrauen-Art\" mit Sahnesoße

angezeigt. In vielen Fällen empfinden Webprogrammierer das aber als störend und schalten magic_quotes_gpc einfach ab. In diesem Fall funktioniert unsere Sicherheitsmaßnahme mit den Anführungsstrichen nicht – der Hacker könnte einfach

548745";
delete from Kontos where KontoNummer = 643894;
select * from Kontos where KontoNummer = "

eingeben. Damit wären wir so schlau wie schon zuvor. Wenn magic_quotes_gpc auf On gesetzt ist, sind wir dagegen fein raus – die Anführungszeichen sind durch die Rückwärtsstriche unschädlich gemacht worden.

Wie überprüfen Sie, ob magic_quotes_gpc auf On gesetzt ist? Wenn Sie Ihren Server selbst installiert haben, können Sie in php.ini nachsehen. Wenn Sie keine Kontrolle über die Serverkonfiguration haben, dann können Sie den Effekt von magic_quotes_gpc On sicherstellen, indem Sie den folgenden Codeschnipsel am Anfang Ihres Skripts einfügen

...
$get_safe = $_GET;
$post_safe = $_POST;
$cookie_safe = $_COOKIE;
if (!get_magic_quotes_gpc()) {
    // Rückwärtsstriche in Browservariablen einfügen
    foreach ($_GET as $key => $value) {
        $get_safe[$key] = addslashes($value);
    }
    foreach ($_POST as $key => $value) {
        $post_safe[$key] = addslashes($value);
    }
    foreach ($_COOKIE as $key => $value) {
        $cookie_safe[$key] = addslashes($value);
    }
}
...

und die "entschärften" Variablen $get_safe, $post_safe, $cookie_safe anstelle von $_GET, $_POST und $_COOKIE verwenden.

Zwischenbilanz

So, damit kennen Sie die geläufigeren Tricks. Wie Sie wahrscheinlich bemerkt haben, haben alle drei Beispiele immer die gleiche fatale Kombination verwendet:

1. vom Browser übergebene Formularvariablen, die unerwartete Strings enthalten können
2. eine Funktion, die außerhalb von PHP Programme ausführt oder Daten bzw. Dateien liest oder ändert

Keine der beiden Zutaten können Sie ohne weiteres umgehen. Sie können aber sicherstellen, daß übergebene Daten entweder genau dem Format entsprechen, das Sie erwarten, oder daß sie vor der Übergabe an die Funktion entschärft werden. Im nächsten Abschnitt sehen wir uns an, wie wir das machen können.