8.2 Cross-Site-Scripting

Bei der Ausgabe von Inhalten muss ein weiterer populärer Angriffspunkt auf Webapplikationen beachtet werden. Cross-Site-Scripting, oft als XSS abgekürzt, bezeichnet das Einschleusen von aktiven Inhalten in einen vertrauenswürdigen Kontext. Nicht autorisierte Besucher einer Webseite sollte es nicht möglich sein, aktive Inhalte wie ECMAScript in die eigene Webseite einzubinden. Wenn andere Besucher die Webseite besuchen und diese als vertrauenswürdig einstufen, erwarten sie nicht, dass fremde Skripte ausgeführt werden, deren Wirkung nicht einschätzbar ist.

Auf den ersten Blick erscheint es nicht besonders gefährlich, fremdes ECMAScript auszuführen, doch lässt sich darüber mit Hilfe der DOM-Funktionen die Webseite manipulieren, Cookies auslesen und fremde Inhalte einbinden. Neben dem Ausspähen privater Daten ist es mit XSS-Lücken auf mehreren Webseiten möglich, gegenseitig referenzierende Nachrichten in verschiedenen Portalen zu platzieren, und damit das Vertrauen des Besuchers in die Authentizität der eingeschleusten Nachrichten noch weiter zu erhöhen. Auf solche Art platzierte Nachrichten, die von vielen Besuchern gelesen werden, können massive Auswirkungen auf die Reputation einzelner Institutionen oder wirtschaftliche Faktoren haben.

Häufig werden eingebettete aktive Inhalte wie ECMAScript auch eingesetzt, um Aktionen auf einer Webseite als eingeloggter Besucher auszuführen. So wäre zum Beispiel ein Skript denkbar, das in einem Administrations-Interface aus dem Kontext des angemeldeten Administrators eine URL aufruft, die dem Angreifer, der das Skript eingebettet hat, mehr Rechte auf der Webseite zuweist.

XSS kann eine massive Bedrohung sein, die bei der Entwicklung beachtet werden muss. Wenn PHP als Template-Sprache zur Generierung von (X)HTML verwendet wird, reicht die Anwendung der PHP-Funktion htmlspecialchars() aus, um vor der Einbettung aktiver Inhalte zu schützen, da sämtliche Zeichen, die für den Interpreter eine nicht-textuelle Bedeutung haben, maskiert werden. Zur Ausgabe einer Variablen $content ist dann minimal der folgende Codeabschnitt zu verwenden.

<?php echo htmlspecialchars( $content ); ?>

Falls die Maskierung nur einer einzigen Variable in der Ausgabe vergessen und von dem Angreifer gefunden wird, ist die Seite durch XSS angreifbar. Gerade von den üblichen Autoren von Templates, den Designern, ist nicht zu erwarten, dass sie diesen Angriffspunkt in ihrer Arbeit ständig berücksichtigen. Bei erhöhter Komplexität der Ausgabelogik ist es außerdem nicht einfach automatisiert sicherzustellen, dass alle ausgegebenen Variablen korrekt maskiert werden.

Auch wenn gewöhnlich nur Eingaben von Benutzern Schadcode enthalten können, und bei applikationseigenen Zeichenketten meistens von ungefährlichen Texten ausgegangen werden kann, ist es besonders für einen Designer schwer festzustellen, auf welche Variablen das zutrifft. So wissen Sie, dass die im $_SERVER-Array enthaltenen Werte wie PHP_SELF Schadcode enthalten können, oder selbst statische Texte, die nur über das Administrations-Interface Ihrer Anwendung zu ändern sind, kompromittiert sein könnten. Aus diesem Grunde ist es generell sinnvoll, alle Zeichenketten – außer explizit angegebenen – zu maskieren.

8.2.1 Ausgabe-Kontext in der Template-Komponente

Um dem Problem nicht-maskierter Ausgaben strukturell vorzubeugen, kennt die Template-Komponente Ausgabe-Kontexte. Der Kontext definiert sich aus dem Zielformat des Templates, üblicherweise (X)HTML. Jedes Ausgabeformat hat spezielle Zeichen, die aktive oder anderweitig problematische Inhalte einleiten können. Aus diesem Grund ist es dem Entwickler möglich, spezifische Kontexte zu verwenden oder eigene Kontexte zu definieren. Die Ausgabe einer Variablen $content unter Berücksichtigung der Maskierung gefährlicher Zeichen gestaltet sich mit der Template-Komponente, wie im folgendem Beispiel gezeigt.

{$content}

Template-Code wird in der Template-Komponente durch geschweifte Klammern eingeschlossen. Die Rückgabe eines Ausdrucks wird nach der kontextsensitiven Maskierung ausgegeben, sodass ein einfacher Ausdruck wie die allein stehende Variable zu ihrer Ausgabe führt.

Für Designer ist es durch die kurze Schreibweise nicht nur einfacher und schneller, Templates zu schreiben, sondern es wird automatisch sichergestellt, dass XSS-Attacken nahezu unmöglich sind. Auf die explizite Möglichkeit, Variableninhalte mit aktivem Inhalt auszugeben, gehen wir später in diesem Kapitel in Abschnitt 8.3.6, »Das pagelayout-Template«, ein.

Ihr Kommentar