Latte ist ein Synonym für Sicherheit

Cross-Site Scripting (XSS)

Cross-Site Scripting (kurz XSS) ist eine der häufigsten Schwachstellen von Webseiten und dabei sehr gefährlich. Es ermöglicht einem Angreifer, ein bösartiges Skript (sog. Malware) in eine fremde Seite einzuschleusen, das im Browser eines ahnungslosen Benutzers ausgeführt wird.

Was kann ein solches Skript alles anrichten? Es kann beispielsweise beliebigen Inhalt von der angegriffenen Seite an den Angreifer senden, einschließlich sensibler Daten, die nach der Anmeldung angezeigt werden. Es kann die Seite verändern oder weitere Anfragen im Namen des Benutzers ausführen. Wenn es sich beispielsweise um einen Webmail-Dienst handeln würde, könnte es sensible Nachrichten lesen, den angezeigten Inhalt verändern oder die Konfiguration ändern, z. B. das Weiterleiten von Kopien aller Nachrichten an die Adresse des Angreifers aktivieren, um auch Zugriff auf zukünftige E-Mails zu erhalten.

Deshalb rangiert XSS auch auf den vorderen Plätzen der gefährlichsten Schwachstellen. Wenn auf einer Webseite eine Schwachstelle auftritt, muss sie so schnell wie möglich beseitigt werden, um Missbrauch zu verhindern.

Wie entsteht die Schwachstelle?

Der Fehler entsteht an der Stelle, an der die Webseite generiert wird und Variablen ausgegeben werden. Stellen Sie sich vor, Sie erstellen eine Suchseite, und am Anfang steht ein Absatz mit dem gesuchten Begriff in der Form:

echo '<p>Suchergebnisse für <em>' . $search . '</em></p>';

Ein Angreifer kann in das Suchfeld und somit in die Variable $search eine beliebige Zeichenkette eingeben, also auch HTML-Code wie <script>alert("Hacked!")</script>. Da die Ausgabe nicht bereinigt wird, wird sie Teil der angezeigten Seite:

<p>Suchergebnisse für <em><script>alert("Hacked!")</script></em></p>

Anstatt die gesuchte Zeichenkette auszugeben, führt der Browser JavaScript aus. Und damit übernimmt der Angreifer die Kontrolle über die Seite.

Man könnte einwenden, dass das Einfügen von Code in die Variable zwar zur Ausführung von JavaScript führt, aber nur im Browser des Angreifers. Wie gelangt es zum Opfer? Aus dieser Perspektive unterscheiden wir verschiedene Arten von XSS. In unserem Beispiel mit der Suche sprechen wir von reflected XSS. Hier muss das Opfer noch dazu gebracht werden, auf einen Link zu klicken, der den bösartigen Code im Parameter enthält:

https://example.com/?search=<script>alert("Hacked!")</script>

Den Benutzer dazu zu bringen, auf einen Link zu klicken, erfordert zwar etwas Social Engineering, ist aber nicht besonders schwierig. Benutzer klicken auf Links, sei es in E-Mails oder in sozialen Netzwerken, ohne groß nachzudenken. Und dass in der Adresse etwas Verdächtiges steht, lässt sich mit einem URL-Shortener verschleiern, der Benutzer sieht dann nur bit.ly/xxx.

Es gibt jedoch auch eine zweite und viel gefährlichere Form des Angriffs, die als stored XSS oder persistent XSS bezeichnet wird, bei der es dem Angreifer gelingt, bösartigen Code auf dem Server so zu speichern, dass er automatisch in einige Seiten eingefügt wird.

Ein Beispiel sind Seiten, auf denen Benutzer Kommentare schreiben. Ein Angreifer sendet einen Beitrag mit Code, und dieser wird auf dem Server gespeichert. Wenn die Seiten nicht ausreichend gesichert sind, wird er dann im Browser jedes Besuchers ausgeführt.

Es könnte scheinen, dass der Kern des Angriffs darin besteht, die Zeichenkette <script> in die Seite zu bekommen. Tatsächlich gibt es viele Möglichkeiten, JavaScript einzufügen. Zeigen wir uns zum Beispiel ein Einfügen über ein HTML-Attribut. Nehmen wir eine Fotogalerie, in der man zu Bildern eine Beschreibung hinzufügen kann, die im alt-Attribut ausgegeben wird:

echo '<img src="' . $imageFile . '" alt="' . $imageAlt . '">';

Dem Angreifer genügt es, als Beschreibung eine geschickt konstruierte Zeichenkette " onload="alert('Hacked!') einzufügen, und wenn die Ausgabe nicht bereinigt wird, sieht der resultierende Code so aus:

<img src="photo0145.webp" alt="" onload="alert('Hacked!')">

Teil der Seite wird nun das eingeschleuste Attribut onload. Der Browser führt den darin enthaltenen Code sofort nach dem Herunterladen des Bildes aus. Gehackt!

Wie wehrt man sich gegen XSS?

Jegliche Versuche, Angriffe durch Blacklisting zu erkennen, wie z. B. das Blockieren der Zeichenkette <script> usw., sind unzureichend. Grundlage einer funktionierenden Verteidigung ist die konsequente Bereinigung aller Daten, die innerhalb der Seite ausgegeben werden.

Vor allem geht es darum, alle Zeichen mit besonderer Bedeutung durch andere entsprechende Sequenzen zu ersetzen, was umgangssprachlich als Escaping bezeichnet wird (das erste Zeichen der Sequenz wird als Escape-Zeichen bezeichnet, daher der Name). Beispielsweise hat im HTML-Text das Zeichen < eine besondere Bedeutung, und wenn es nicht als Anfang eines Tags interpretiert werden soll, müssen wir es durch eine visuell entsprechende Sequenz ersetzen, die sogenannte HTML-Entität <. Und der Browser gibt das Kleiner-als-Zeichen aus.

Sehr wichtig ist es, den Kontext zu unterscheiden, in dem wir Daten ausgeben. Denn in verschiedenen Kontexten werden Zeichenketten unterschiedlich bereinigt. In verschiedenen Kontexten haben unterschiedliche Zeichen eine besondere Bedeutung. Beispielsweise unterscheidet sich das Escaping im HTML-Text, in HTML-Attributen, innerhalb einiger spezieller Elemente usw. Wir werden das gleich im Detail besprechen.

Die Bereinigung erfolgt am besten direkt bei der Ausgabe der Zeichenkette auf der Seite, wodurch sichergestellt wird, dass sie wirklich durchgeführt wird und genau einmal erfolgt. Am besten ist es, wenn die Bereinigung automatisch direkt vom Template-System übernommen wird. Denn wenn die Bereinigung nicht automatisch erfolgt, kann der Programmierer sie vergessen. Und ein Versäumnis bedeutet, dass die Website anfällig ist.

XSS betrifft jedoch nicht nur die Ausgabe von Daten in Templates, sondern auch andere Teile der Anwendung, die mit nicht vertrauenswürdigen Daten korrekt umgehen müssen. Beispielsweise ist es notwendig, dass JavaScript in Ihrer Anwendung im Zusammenhang damit nicht innerHTML, sondern nur innerText oder textContent verwendet. Besondere Vorsicht ist bei Funktionen geboten, die Zeichenketten als JavaScript auswerten, was eval(), aber auch setTimeout() oder die Verwendung der Funktion setAttribute() mit Event-Attributen wie onload usw. ist. Dies geht jedoch über den Bereich hinaus, den Templates abdecken.

Die ideale Verteidigung in 3 Punkten:

1. erkennt den Kontext, in dem die Daten ausgegeben werden
2. bereinigt die Daten gemäß den Regeln des jeweiligen Kontexts (also „kontextsensitiv“)
3. tut dies automatisch

Kontextsensitives Escaping

Was genau ist mit dem Wort Kontext gemeint? Es handelt sich um eine Stelle im Dokument mit eigenen Regeln für die Bereinigung ausgegebener Daten. Sie hängt vom Dokumenttyp ab (HTML, XML, CSS, JavaScript, Plain Text, …) und kann sich in seinen spezifischen Teilen unterscheiden. Beispielsweise gibt es in einem HTML-Dokument eine ganze Reihe solcher Stellen (Kontexte), an denen sehr unterschiedliche Regeln gelten. Vielleicht werden Sie überrascht sein, wie viele es sind. Hier sind die ersten vier:

<p>#text</p>
<img src="#attribut">
<textarea>#rawtext</textarea>
<!-- #kommentar -->

Der Standard- und Grundkontext einer HTML-Seite ist HTML-Text. Welche Regeln gelten hier? Eine besondere Bedeutung haben die Zeichen < und &, die den Anfang eines Tags oder einer Entität darstellen, daher müssen wir sie escapen, und zwar durch Ersetzen durch eine HTML-Entität (< durch <, & durch &amp).

Der zweithäufigste Kontext ist der Wert eines HTML-Attributs. Er unterscheidet sich vom Text dadurch, dass hier das Anführungszeichen " oder ', das das Attribut begrenzt, eine besondere Bedeutung hat. Es muss als Entität geschrieben werden, damit es nicht als Ende des Attributs verstanden wird. Im Attribut kann das Zeichen < hingegen sicher verwendet werden, da es hier keine besondere Bedeutung hat, hier kann es nicht als Anfang eines Tags oder Kommentars verstanden werden. Aber Vorsicht, in HTML können Attributwerte auch ohne Anführungszeichen geschrieben werden, in diesem Fall hat eine ganze Reihe von Zeichen eine besondere Bedeutung, es handelt sich also um einen weiteren separaten Kontext.

Vielleicht überrascht es Sie, aber spezielle Regeln gelten innerhalb der Elemente <textarea> und <title>, wo das Zeichen < nicht (aber kann) escapet werden muss, wenn ihm kein / folgt. Aber das ist eher eine Randnotiz.

Interessant ist es innerhalb von HTML-Kommentaren. Hier wird nämlich kein Escaping mit HTML-Entitäten verwendet. Tatsächlich gibt keine Spezifikation an, wie in Kommentaren escapet werden soll. Man muss nur etwas kuriose Regeln einhalten und bestimmte Zeichenkombinationen darin vermeiden.

Kontexte können sich auch verschachteln, was passiert, wenn wir JavaScript oder CSS in HTML einbetten. Dies kann auf zwei verschiedene Arten geschehen, mit einem Element und einem Attribut:

<script>#js-element</script>
<img onclick="#js-attribut">

<style>#css-element</style>
<p style="#css-attribut"></p>

Zwei Wege und zwei verschiedene Arten des Escapings von Daten. Innerhalb der Elemente <script> und <style> erfolgt, wie bei HTML-Kommentaren, kein Escaping mit HTML-Entitäten. Bei der Ausgabe von Daten innerhalb dieser Elemente muss nur eine Regel beachtet werden: Der Text darf nicht die Sequenz </script bzw. </style enthalten.

Im Gegensatz dazu wird in den Attributen style und on*** mit HTML-Entitäten escapet.

Und natürlich gelten innerhalb des verschachtelten JavaScripts oder CSS die Escaping-Regeln dieser Sprachen. Eine Zeichenkette im Attribut, z. B. onload, wird also zuerst nach den Regeln von JS und dann nach den Regeln des HTML-Attributs escapet.

Uff… Wie Sie sehen, ist HTML ein sehr komplexes Dokument, in dem sich Kontexte verschachteln, und ohne zu wissen, wo genau ich Daten ausgebe (d. h. in welchem Kontext), kann man nicht sagen, wie man es richtig macht.

Möchten Sie ein Beispiel?

Nehmen wir die Zeichenkette Rock'n'Roll.

Wenn Sie sie im HTML-Text ausgeben, müssen in diesem Fall keine Ersetzungen vorgenommen werden, da die Zeichenkette kein Zeichen mit besonderer Bedeutung enthält. Eine andere Situation ergibt sich, wenn Sie sie innerhalb eines HTML-Attributs ausgeben, das in einfache Anführungszeichen eingeschlossen ist. In diesem Fall müssen die Anführungszeichen in HTML-Entitäten escapet werden:

<div title='Rock&apos;n&apos;Roll'></div>

Das war einfach. Eine viel interessantere Situation ergibt sich bei der Verschachtelung von Kontexten, zum Beispiel wenn die Zeichenkette Teil von JavaScript ist.

Zuerst geben wir sie also in JavaScript selbst aus. D. h., wir schließen sie in Anführungszeichen ein und escapen gleichzeitig die darin enthaltenen Anführungszeichen mit einem Backslash \:

'Rock\'n\'Roll'

Wir können noch den Aufruf einer Funktion hinzufügen, damit der Code etwas tut:

alert('Rock\'n\'Roll');

Wenn wir diesen Code mit <script> in ein HTML-Dokument einfügen, muss nichts weiter geändert werden, da die verbotene Sequenz </script nicht darin vorkommt:

<script> alert('Rock\'n\'Roll'); </script>

Wenn wir ihn jedoch in ein HTML-Attribut einfügen wollten, müssten wir die Anführungszeichen noch in HTML-Entitäten escapen:

<div onclick='alert(&apos;Rock\&apos;n\&apos;Roll&apos;)'></div>

Ein verschachtelter Kontext muss aber nicht nur JS oder CSS sein. Häufig ist es auch eine URL. Parameter in einer URL werden escapet, indem Zeichen mit besonderer Bedeutung in Sequenzen umgewandelt werden, die mit % beginnen. Beispiel:

https://example.org/?a=Jazz&b=Rock%27n%27Roll

Und wenn wir diese Zeichenkette in einem Attribut ausgeben, wenden wir noch das Escaping gemäß diesem Kontext an und ersetzen & durch &amp:

<a href="https://example.org/?a=Jazz&amp;b=Rock%27n%27Roll">

Wenn Sie bis hierher gelesen haben, herzlichen Glückwunsch, es war anstrengend. Jetzt haben Sie eine gute Vorstellung davon, was Kontexte und Escaping sind. Und Sie müssen keine Angst haben, dass es kompliziert ist. Latte erledigt das nämlich automatisch für Sie.

Latte vs. naive Systeme

Wir haben gezeigt, wie man in einem HTML-Dokument korrekt escapet und wie entscheidend die Kenntnis des Kontexts ist, also des Ortes, an dem wir Daten ausgeben. Mit anderen Worten, wie kontextsensitives Escaping funktioniert. Obwohl dies eine notwendige Voraussetzung für eine funktionierende Abwehr von XSS ist, ist Latte das einzige Template-System für PHP, das dies kann.

Wie ist das möglich, wenn alle Systeme heute behaupten, automatisches Escaping zu haben? Automatisches Escaping ohne Kontextkenntnis ist ein bisschen Blödsinn, der ein falsches Gefühl der Sicherheit erzeugt.

Template-Systeme wie Twig, Laravel Blade und andere sehen keine HTML-Struktur im Template. Sie sehen daher auch keine Kontexte. Im Gegensatz zu Latte sind sie blind und naiv. Sie verarbeiten nur ihre eigenen Tags, alles andere ist für sie ein unwichtiger Zeichenstrom:

░░░░░░░░░░░░░░░░░{{ foo }}░░░░░░░
░░░░░░░░░░░░░░░░{{ foo }}░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░{{ foo }}░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░{{ foo }}░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░{{ foo }}░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░{{ foo }}░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░{{ foo }}░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░{{ foo }}░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░{{ foo }}░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░{{ foo }}░░░░

- im Text: <span>{{ foo }}</span>
- im Tag: <span {{ foo }} ></span>
- im Attribut: <span title='{{ foo }}'></span>
- im Attribut ohne Anführungszeichen: <span title={{ foo }}></span>
- im Attribut, das eine URL enthält: <a href="{{ foo }}"></a>
- im Attribut, das JavaScript enthält: <img onload="{{ foo }}">
- im Attribut, das CSS enthält: <span style="{{ foo }}"></span>
- in JavaScript: <script>var = {{ foo }}</script>
- in CSS: <style>body { content: {{ foo }}; }</style>
- im Kommentar: <!-- {{ foo }} -->

Naive Systeme konvertieren nur mechanisch die Zeichen < > & ' " in HTML-Entitäten, was zwar in den meisten Anwendungsfällen eine gültige Escaping-Methode ist, aber bei weitem nicht immer. Sie können daher verschiedene Sicherheitslücken weder aufdecken noch verhindern, wie wir weiter unten zeigen werden.

Latte sieht das Template genauso wie Sie. Es versteht HTML, XML, erkennt Tags, Attribute usw. Und dank dessen unterscheidet es einzelne Kontexte und bereinigt die Daten entsprechend. Es bietet somit einen wirklich effektiven Schutz gegen die kritische Schwachstelle Cross-Site Scripting.

░░░░░░░░░░░<span>{$foo}</span>
░░░░░░░░░░<span {$foo} ></span>
░░░░░░░░░░░░░░<span title='{$foo}'></span>
░░░░░░░░░░░░░░░░░░░░░░░░░░░<span title={$foo}></span>
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░<a href="{$foo}"></a>
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░<img onload="{$foo}">
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░<span style="{$foo}"></span>
░░░░░░░░░░░░░░░░░<script>░░░░░░{$foo}</script>
░░░░░░░░░<style>░░░░░░░░░░░░░░░░{$foo}░░░</style>
░░░░░░░░░░░░░░░<!--░{$foo}░-->

- im Text: <span>{$foo}</span>
- im Tag: <span {$foo} ></span>
- im Attribut: <span title='{$foo}'></span>
- im Attribut ohne Anführungszeichen: <span title={$foo}></span>
- im Attribut, das eine URL enthält: <a href="{$foo}"></a>
- im Attribut, das JavaScript enthält: <img onload="{$foo}">
- im Attribut, das CSS enthält: <span style="{$foo}"></span>
- in JavaScript: <script>var = {$foo}</script>
- in CSS: <style>body { content: {$foo}; }</style>
- im Kommentar: <!-- {$foo} -->

Live-Demo

Links sehen Sie das Template in Latte, rechts den generierten HTML-Code. Die Variable $text wird hier mehrmals ausgegeben, und jedes Mal in einem etwas anderen Kontext. Und daher auch etwas anders escapet. Sie können den Code des Templates selbst bearbeiten, zum Beispiel den Inhalt der Variablen ändern usw. Probieren Sie es aus:

{* VERSUCHEN SIE, DIESES TEMPLATE ZU BEARBEITEN *}
{var $text = "Rock'n'Roll"}
- <span>{$text}</span>
- <span title='{$text}'></span>
- <span title={$text}></span>
- <img onload="{$text}">
- <script>var = {$text}</script>
- <!-- {$text} -->

- <span>Rock'n'Roll</span>
- <span title='Rock&apos;n&apos;Roll'></span>
- <span title="Rock&apos;n&apos;Roll"></span>
- <img onload="&quot;Rock&apos;n&apos;Roll&quot;">
- <script>var = "Rock'n'Roll"</script>
- <!-- Rock'n'Roll -->

Ist das nicht großartig! Latte erledigt das kontextsensitive Escaping automatisch, sodass der Programmierer:

• nicht darüber nachdenken oder wissen muss, wie wo escapet wird
• sich nicht irren kann
• das Escaping nicht vergessen kann

Das sind sogar nicht alle Kontexte, die Latte bei der Ausgabe unterscheidet und für die es die Datenbereinigung anpasst. Weitere interessante Fälle gehen wir jetzt durch.

Wie man naive Systeme hackt

Anhand einiger praktischer Beispiele zeigen wir, wie wichtig die Unterscheidung von Kontexten ist und warum naive Template-Systeme keinen ausreichenden Schutz vor XSS bieten, im Gegensatz zu Latte. Als Vertreter eines naiven Systems verwenden wir in den Beispielen Twig, aber dasselbe gilt auch für andere Systeme.

Schwachstelle durch Attribut

Wir versuchen, bösartigen Code über ein HTML-Attribut in die Seite einzuschleusen, wie wir es oben gezeigt haben. Nehmen wir ein Template in Twig, das ein Bild rendert:

<img src={{ imageFile }} alt={{ imageAlt }}>

Beachten Sie, dass um die Attributwerte keine Anführungszeichen stehen. Der Programmierer könnte sie vergessen haben, was einfach passiert. Beispielsweise wird in React Code so geschrieben, ohne Anführungszeichen, und ein Programmierer, der zwischen Sprachen wechselt, kann die Anführungszeichen dann leicht vergessen.

Ein Angreifer fügt als Bildbeschreibung eine geschickt konstruierte Zeichenkette foo onload=alert('Hacked!') ein. Wir wissen bereits, dass Twig nicht erkennen kann, ob die Variable im Fluss des HTML-Textes, innerhalb eines Attributs, eines HTML-Kommentars usw. ausgegeben wird, kurz gesagt, es unterscheidet keine Kontexte. Und konvertiert nur mechanisch die Zeichen < > & ' " in HTML-Entitäten. Der resultierende Code sieht also so aus:

<img src=photo0145.webp alt=foo onload=alert(&#039;Hacked!&#039;)>

Und eine Sicherheitslücke ist entstanden!

Teil der Seite wurde das eingeschleuste Attribut onload, und der Browser führt es sofort nach dem Herunterladen des Bildes aus.

Sehen wir uns nun an, wie Latte mit demselben Template umgeht:

<img src={$imageFile} alt={$imageAlt}>

Latte sieht das Template genauso wie Sie. Im Gegensatz zu Twig versteht es HTML und weiß, dass die Variable als Wert eines Attributs ausgegeben wird, das nicht in Anführungszeichen steht. Deshalb ergänzt es sie. Wenn ein Angreifer dieselbe Beschreibung einfügt, sieht der resultierende Code so aus:

<img src="photo0145.webp" alt="foo onload=alert(&apos;Hacked!&apos;)">

Latte hat XSS erfolgreich verhindert.

Ausgabe einer Variablen in JavaScript

Dank kontextsensitivem Escaping ist es ganz nativ möglich, PHP-Variablen innerhalb von JavaScript zu verwenden.

<p onclick="alert({$movie})">{$movie}</p>

<script>var movie = {$movie};</script>

Wenn die Variable $movie die Zeichenkette 'Amarcord & 8 1/2' enthält, wird folgende Ausgabe generiert. Beachten Sie, dass innerhalb von HTML ein anderes Escaping verwendet wird als innerhalb von JavaScript und noch ein anderes im Attribut onclick:

<p onclick="alert(&quot;Amarcord &amp; 8 1\/2&quot;)">Amarcord &amp; 8 1/2</p>

<script>var movie = "Amarcord & 8 1\/2";</script>

Überprüfung von Links

Latte überprüft automatisch, ob eine in den Attributen src oder href verwendete Variable eine Web-URL enthält (d. h. das HTTP-Protokoll) und verhindert die Ausgabe von Links, die ein Sicherheitsrisiko darstellen können.

{var $link = 'javascript:attack()'}

<a href={$link}>klicken</a>

Gibt aus:

<a href="">klicken</a>

Die Überprüfung kann mit dem Filter nocheck deaktiviert werden.

Grenzen von Latte

Latte ist kein vollständiger Schutz vor XSS für die gesamte Anwendung. Wir möchten nicht, dass Sie bei der Verwendung von Latte aufhören, über Sicherheit nachzudenken. Das Ziel von Latte ist es sicherzustellen, dass ein Angreifer die Struktur der Seite nicht verändern, HTML-Elemente oder Attribute einschleusen kann. Aber es prüft nicht die inhaltliche Korrektheit der ausgegebenen Daten. Oder die Korrektheit des JavaScript-Verhaltens. Das geht über die Kompetenzen eines Template-Systems hinaus. Die Überprüfung der Korrektheit von Daten, insbesondere der vom Benutzer eingegebenen und somit nicht vertrauenswürdigen Daten, ist eine wichtige Aufgabe des Programmierers.