Teil 2: PHP-Zertifizierung
- PHP-Zertifizierung
- Teil 2: PHP-Zertifizierung
- Teil 3: PHP-Zertifizierung
Das Phänomen ungefilterter Ausgaben nennt man Cross Site Scripting oder kurz XSS. Das X erklärt sich aus Crossing, dem englischen Wort für Kreuzung. Das X ist das entsprechende Symbol auf Verkehrsschildern. Außerdem war im Web die entsprechende Abkürzung CSS schon besetzt. Der Begriff selbst ...
Das Phänomen ungefilterter Ausgaben nennt man Cross Site Scripting oder kurz XSS. Das X erklärt sich aus Crossing, dem englischen Wort für Kreuzung. Das X ist das entsprechende Symbol auf Verkehrsschildern. Außerdem war im Web die entsprechende Abkürzung CSS schon besetzt.
Der Begriff selbst erklärt sich darin, wie die schadhaften Aufrufe beim Nutzer landen. Hierfür gibt es zwei Ansätze: Das typische Beispiel für den ersten Ansatz ist ein Gästebuch. Wenn dort HTML-Code nicht ausgefiltert wird, landet er permanent im Datenspeicher des Gästebuchs, also einer Datei oder einer Datenbank auf dem Server. Das heißt auch, jeder Nutzer, der die Ausgabeseite des Gästebuchs aufruft, verliert sein Cookie an ein per Javascript erzeugtes Bild.
Aber auch wenn Ihr Skript die Daten nicht speichert, sind XSS-Lücken gefährlich. Denken Sie an die vielen Links, die in E-Mails versendet werden. Wird ein per XSS-verseuchter Link vom Nutzer angeangeklickt, wandert dessen Cookie ebenfalls an den Angreifer.
Die Vermeidung des Problems ist, wie Sie vielleicht schon wissen oder geahnt haben, sehr einfach. Sie sollten die entsprechenden Daten einfach vor der Ausgabe filtern. PHP bietet hierfür die Funktion htmlspecialchars(String, Anführungszeichen). Sie wandelt problematische Sonderzeichen im übergebenen String um:
& wird zu & " wird zu " < wird zu < > wird zu >
Die Umwandlung der Anführungszeichen ist noch von Flags abhängig. ENT_QUOTES heißt, dass sowohl doppelte als auch einfache Anführungszeichen umgewandelt werden. ENT_NOQUOTES bedeutet, dass Anführungszeichen nicht konvertiert werden. Es reicht die normale Umwandlung:
<?php
setcookie("meinCookie",
"Sitzungs-ID");
if (isset($_GET['parameter'])) {
echo htmlspecialchars($_GET
['parameter']);}
?>Übrigens, wer noch ein wenig mehr filtern möchte, kann auch htmlentitites() einsetzen. Im Gegensatz zu htmlspecialchars() werden hier auch Umlaute und andere HTML-relevante Zeichen in ihre entsprechenden Entitäten umgewandelt. Eine andere Funktion wird manchmal als Lösung für XSS-Probleme genannt: strip_tags(). Sie entfernt HTML-Tags. Dies tut sie zuverlässig und auch bei unterschiedlichen Zeichensätzen.
Einen Haken aber gibt es: Für Javascript-Code sind nicht unbedingt Tags notwendig. Wenn Sie einen Attributswert aus einem Parameter befüllen, kann auch dort einfach Code eingeschleust werden. Einige Beispiele sehen Sie unter .
Andere Ansätze wie eine eigene Filterfunktion, die auf einer Blacklist, was nicht erlaubt ist, sind nicht hilfreich. Das Risiko liegt hier in den umfangreichen Möglichkeiten wie beispielsweise den Javascript-Event-Handlern. In der Zertifizierungsprüfung und in der Realität ist XSS eine durchaus komplexe Sache. Oft sind ungefilterte Ausgaben im gezeigten Code gut versteckt. Hier lohnt also ein sehr genauer Blick, wenn es um Sicherheitsfragen geht.
Cross Site Request Forgeries
Eine mögliche Basis von Cross Site Request Forgeries sind XSS-Attacken. Bei Cross Site Request Forgeries geht der Angreifer davon aus, dass der Nutzer in einer Anwendung eingeloggt ist. Dann wird diesem Nutzer eine URL untergejubelt, die eine bestimmte Aktion durchführt - beispielsweise einen neuen Nutzer für den Angreifer erstellt.
Die URL kann auf verschiedene Arten untergeschoben werden. Per E-Mail ist natürlich ein Link verschickbar. Über einen URL-Dienst für kurze URLs (zum Beispiel Tiny URL) kann hier sogar noch zusätzliche Verschleierung eingeführt werden. Eine andere Möglichkeit ist, den Nutzer auf die eigene Site zu locken, während er beim Dienst, der angegriffen werden soll, eingeloggt ist.
Auf der eigenen Site des Angreifers befindet sich dann beispielsweise ein versteckter iFrame oder ein Tag mit URL wie <object>, <img> oder ähnlich. Darin ist dann die Anfrage an den anzugreifenden Dienst enthalten. Dieser prüft zwar den Nutzer, aber stellt nicht fest, ob die Abfrage auch beabsichtigt war. Als Sicherungsmaßnahmen bietet es sich an, ein eindeutiges Token in das Formular einzubauen, das der Angreifer dann erst mal klauen müsste. Auch ein erneutes Log-in vor gefährlichen Aktionen ist ein möglicher Schutz. Darauf setzt beispielsweise Amazon bei Bestellungen.
SQL-Injection
Die zweite besonders bekannte Lücke neben XSS ist die SQL Injection. Aufgrund des meist hohen Risikofaktors wird sie in der Praxis etwas häufiger gefiltert. Dennoch belegt sie neben anderen Injection-Sicherheitslücken immer noch Rang 2 in der OWASP Top 10 2007 (). Sehen Sie sich das folgende Beispiel an:
<?php
if (isset($_POST['username'])&& isset($_POST['password'])) {
$user = $_POST['username'];
$pass = $_POST['password'];
$sql = 'SELECT * FROM users
WHERE username=\''.$user.'\' AND password=\''.$pass.'\'";
// Schicke $sql an die Datenbank
}
?>
