Jinja: Autoescaping standardmäßig deaktiviert ist eine gefährliche Standardeinstellung

Erstellt am 6. Jan. 2016  ·  4Kommentare  ·  Quelle: pallets/jinja

Ich habe heute durch ein extern gemeldetes XSS festgestellt, dass Jinja standardmäßig die automatische Escape-Funktion nicht aktiviert. Dies ist ein gefährlicher Standard, der noch gefährlicher wird durch die Tatsache, dass viele Leute Jinja durch ihre Vorkenntnisse über Django-Vorlagen kennen lernen, die seit 2007 standardmäßig automatisches Escape-Funktion aktiviert haben.

Wenn man sich das Internet ansieht, scheint diese Tatsache nicht sehr bekannt zu sein. Tatsächlich habe ich sogar Bücher gefunden (Python 3 Object Oriented Programming, Kapitel 12, cc @buchuki), in denen empfohlen wird, jinja2 für Websites zu verwenden und die automatische Escape-Funktion deaktiviert zu lassen. Eine zufällige Auswahl von Github-Projekten zeigt auch, dass die meisten Leute ihrem Projekt weder autoescape=True noch die autoescape-Erweiterung hinzufügen.

Obwohl ich verstehe, dass es wahrscheinlich mühsam wäre, zu diesem Zeitpunkt zu einem sichereren Standard zu migrieren, sollte die Dokumentation zumindest deutlich machen, dass die automatische Escape-Funktion standardmäßig deaktiviert ist. Fügen Sie vielleicht autoescape=True zu allen Beispielen hinzu, die ein jinja2.Environment-Objekt erstellen, und/oder fügen Sie einen Abschnitt sehr früh in der Dokumentation hinzu.

docs

Hilfreichster Kommentar

Klingt nach einem guten Kandidaten für einen Pull Request :)

Alle 4 Kommentare

Jinja ist nicht nur für HTML, sondern eine universelle Template-Engine. Ich denke, die meisten Leute verwenden Jinja in Flask, das standardmäßig Autoescape für HTML-Vorlagen aktiviert. Wenn Sie eine Template-Engine in Ihr eigenes Framework integrieren, sollten Sie die Dokumentation zur sicheren Verwendung lesen.

Trotzdem denke ich, dass es ein guter Vorschlag ist, in den Dokumenten sehr klar zu sein, dass Sie beim Generieren von HTML wahrscheinlich Autoescape verwenden sollten.

Ich würde davon ausgehen, dass die meisten großen Frameworks dies richtig machen (mehr Augen, weniger Fehler usw.), aber es gibt auch viele kleinere Projekte, die Jinja manuell integrieren, die diesen Fehler machen.

Und um ehrlich zu sein, Jinjas Dokumentation zu diesem Thema ist wirklich schlecht. Folgendes sehen Sie zuerst, wenn Sie Jinjas Dokumentation öffnen:

Jinja2 ist eine moderne und designerfreundliche Templating-Sprache für Python, die den Vorlagen von Django nachempfunden ist. Es ist schnell, weit verbreitet und sicher mit der optionalen Umgebung für die Ausführung von Vorlagen in einer Sandbox:

"nach Djangos Vorlagen modelliert" und "sicher" könnte vermuten lassen, dass sie über Sicherheitsfunktionen von Djangos Vorlagen wie Autoescaping verfügt.

Dann ein Beispiel, das HTML ist. Und gleich danach in der Liste der Funktionen:

leistungsstarkes automatisches HTML-Escape-System zur XSS-Prävention

Was nicht erwähnt, dass es optional und standardmäßig nicht aktiviert ist.

Auf der Dokumentationsseite "Grundlegende API-Verwendung" wird die automatische Escape-Funktion nicht angezeigt, aber auch kein HTML, also denke ich, dass das in Ordnung ist. Aber wenn Sie dann auf die API-Seite "Grundlagen" gehen :

from jinja2 import Environment, PackageLoader
env = Environment(loader=PackageLoader('yourapplication', 'templates'))
template = env.get_template('mytemplate.html')
print template.render(the='variables', go='here')

Das erste Beispiel ist anfällig für triviale XSSes. Die Leute haben Recht, verwirrt zu sein.

Klingt nach einem guten Kandidaten für einen Pull Request :)

Wir können das jetzt nicht ausschalten, ohne den Code aller zu knacken. Ich freue mich jedoch, die Dokumente entsprechend zu aktualisieren. Ich werde dies als Wontfix schließen, aber fühlen Sie sich frei, eine PR für Dokumentationsaktualisierungen zu öffnen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen