<p>MathJax erfordert unsichere „Content Security Policy“</p>

Erstellt am 11. Juni 2012  ·  42Kommentare  ·  Quelle: mathjax/MathJax

Die aktuelle MathJax-Implementierung verwendet die folgenden Funktionen, die in der modernen Welt nicht als sicher gelten und nicht mit standardmäßigen Content-Security-Policy-Headern (http://www.w3.org/TR/CSP/) verwendet werden können:

  • JavaScript-Auswertung von Strings (neue Function() mit einem String oder eval()) (1)
  • Per JavaScript eingefügte Inline-Stilattribute (2)

Es ist fraglich, ob Problem (2) behoben werden sollte, aber zumindest (1) sollte behoben werden, da Content-Security-Policy nicht über genügend Granularität verfügt, um MathJax als vertrauenswürdiges Skript auszuführen und gleichzeitig nicht jedes andere JavaScript zu interpretieren Datei als besonders vertrauenswürdig. Wenn man derzeit MathJax verwenden möchte, muss man eval() überall zulassen. Das Problem (1) verursacht auch Fehler Nr. 130 (MathJax ist mit dem strengen Modus von ECMAScript 5 nicht kompatibel).

Derzeit besteht die einzige Möglichkeit, MathJax zum Laufen zu bringen, selbst wenn man lokal installierten MathJax-Code verwendet, darin, die folgenden CSP-HTTP-Header zu verwenden (der veraltete "Options"-Header ist für Firefox 13.0 und niedriger enthalten):

X-Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; options eval-script
X-WebKit-CSP: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'

Diese Header ermöglichen einen gewissen, vom CSP bereitgestellten Schutz und erlauben dennoch, dass MathJax funktioniert, wenn MathJax vom selben Ursprung wie der Seiteninhalt verteilt wird.

Accepted Fixed Test Not Needed v2.4

Hilfreichster Kommentar

@kaushalmodi , siehe meinen Kommentar oben zur Vermeidung des Problems oder meinen Kommentar zu dem Problem, auf das Sie verlinken. Sie müssen die Konfiguration von MathJax ändern, wenn Sie einen CSP verwenden, der die Skriptausführung einschränkt.

Alle 42 Kommentare

Unsafe Eval ist auch ein großes Problem für mich. Sehr bald wird Chrome alle Erweiterungen dazu zwingen, eine Inhaltssicherheitsrichtlinie zu übernehmen, die die Verwendung von eval verbietet. Wir versuchen derzeit, Readium zu aktualisieren, um dies zu erfüllen, aber wir können dies nicht tun und MathJax verwenden

+1

Danke Leute. Wir werden es prüfen.

Nur ein vorläufiges Update. Es scheint möglich, einige der Probleme bald genug zu beheben (hoffentlich genug für den Chrome Store). Wir sind uns jedoch nicht sicher, wie die Leistung leiden wird – was, wie Sie sich vorstellen können, schlecht sein könnte. Wir werden Sie auf dem Laufenden halten, wenn @dpvc sich dies genauer ansehen und vielleicht einige experimentelle Zweige erstellen kann.

Wenn Sie weitere Kommentare, Fragen und Vorschläge zu bestimmtem Code haben, teilen Sie uns dies bitte mit.

Ich habe ein wenig Zeit damit verbracht, mich selbst darum zu kümmern. Es scheint, als müssten Sie mit der vorzeitigen Optimierung aufhören. Das Auswerten einer Zeichenfolge ist NICHT schneller als das Erstellen eines Abschlusses.

Außerdem sollten Sie nicht eval() auf jeder Seite ausführen, die Mathjax lädt, nur um zu prüfen, ob Sie eval() ausführen können. Das muss grundsätzlich weg.

Die new Function() -Aufrufe dienen nicht der Geschwindigkeit, sondern dem Speicher. Das new Function() erstellt keinen Abschluss und behält daher nicht den lokalen Gültigkeitsbereich bei. Da dies das Herzstück des objektorientierten Programmiermodells ist und viele Objekte verwendet werden, könnte dies Auswirkungen auf die Speichernutzung haben. Ich habe das in neueren Browsern nicht getestet.

Was die Verwendung von eval anbelangt, verwendet MathJax es, um seine Inline-Konfigurationsblöcke zu handhaben, und das könnte zu diesem Zeitpunkt nicht einfach ersetzt werden. Eine "sichere" Version von MathJax müsste also externe Konfigurationsdateien verwenden (was kein Problem sein sollte und wahrscheinlich ohnehin eher mit der Sicherheitsrichtlinie übereinstimmt). Der eval -Aufruf, auf den Sie sich beziehen, dient nicht dazu festzustellen, ob eval ausgeführt werden kann, sondern um festzustellen, ob es im globalen Namensraum ausgeführt wird (was nicht in allen Browsern der Fall ist). Mir ist bewusst, dass dies für eine Version, die Ihren Sicherheitsanforderungen entspricht, entfernt werden müsste.

So funktionieren Closures in Javascript nicht . Sie halten nicht alles im lokalen Rahmen fest; Sie erfassen nur Dinge, die Ihre Funktion verwendet. Ihre CONSTRUCTOR -Funktion verwendet nichts aus dem lokalen Bereich, es fallen keine Kosten für die Erstellung des Abschlusses an. Dies ist eine vorzeitige Optimierung für ein Problem, das nie existiert hat.

Soweit es um eval geht, ist mein Punkt, dass Sie keinen Code auf einer Seite ausführen sollten, wenn dies nicht erforderlich ist, insbesondere wenn dieser Code unsichere eval() verwendet. Sie verwenden diese EVAL -Funktion nur, wenn Mathjax in der Inline-Konfiguration enthalten ist, also führen Sie den Test erst dann aus, wenn Sie es brauchen. Aber wirklich, warum um alles in der Welt muss die Konfiguration ausführbarer Code sein. Es ist wirklich nur ein Stück JSON, das an die Funktion übergeben wird. Warum nicht einfach JSON übergeben, parsen und MathJAX die Funktion aufrufen lassen?

So funktionieren Closures in Javascript nicht . Sie halten nicht alles im lokalen Rahmen fest; Sie erfassen nur Dinge, die Ihre Funktion verwendet.

Ich glaube nicht, dass die Dinge so eindeutig sind. Erstens war dies 2008 _nicht_ der Fall, als dieser Teil des Codes geschrieben wurde. Ich habe gerade heute Morgen Tests durchgeführt, die zu bestätigen scheinen, dass die Versionen von Safari, Firefox, Opera und IE, die zu diesem Zeitpunkt im Spiel waren, alle so funktionierten, wie ich es beschrieben habe (die vollständige Scope-Kette wurde unabhängig von den verwendeten Variablen in einer Schließung beibehalten ). Die Site, die meine Referenz dafür ist, scheint heute Morgen nicht verfügbar zu sein (war gestern online), daher kann ich keine Details überprüfen, aber ich erinnere mich, dass dies Teil der ECMAScript 262-Spezifikation war.

Aktuelle Versionen von Safari, Chrome, Firefox und IE scheinen so zu funktionieren, wie Sie es beschreiben, also haben sich die Dinge seitdem irgendwo geändert. Es sieht so aus, als ob die Änderung in Safari 4, Firefox 3.6 und IE9 stattfand; Ich habe keine alten Versionen von Chrome zum Testen, kenne also den Verlauf dort nicht. IE8 hat das ältere Verhalten und Opera 12 tut es immer noch. Mobilgeräte habe ich nicht überprüft. Einige dieser Browser stehen auf der Support-Liste von MathJax, daher ist dies immer noch ein Problem, das wir für MathJax im Allgemeinen berücksichtigen müssen. Natürlich bin ich sicher, dass etwas für Ihre Bedürfnisse ausgearbeitet werden kann.

Bei JSON-Daten kann der Konfigurationsblock mehr als nur ein MathJax.Hub.Config() -Aufruf sein. Beispielsweise können Sie Ereignis-Listener installieren oder dem TeX-Eingabe-JAX Funktionen hinzufügen, um zusätzliche Befehle zu implementieren, und so weiter. Diese können nicht Teil von JSON-Daten sein, da sie ausführbaren Code enthalten. Diese Funktion wird nicht immer verwendet, aber sie _wird_ sicherlich von tatsächlichen Websites verwendet. Darüber hinaus verfügen nicht alle Zielbrowser über eine integrierte JSON-Bibliothek, sodass zusätzliche Bibliotheken für die Analyse erforderlich wären. (Sicherlich nicht unüberwindbar, aber mehr Code zum Herunterladen.)

+1 für die Änderung, damit (unter anderem) Github MathJax wieder in ihren Wikis zulässt.

@ketch haben Sie eine Referenz für Github, die diesbezüglich eine Aussage macht? Ich sehe nicht, wie dieses Problem die Github-Wiki-Sicherheit berührt.

@pkra Ich weiß nicht genau, ob dies die Ursache ist, aber ich glaube, es ist so. Darauf bin ich durch die Kommentare auf dieser Seite aufmerksam geworden:

http://stackoverflow.com/questions/16889421/how-to-insert-javascript-to-enable-mathjax-on-github-wiki-pages

Und sehen

https://github.com/blog/1477-content-security-policy

Ich glaube, die MathJax-Unterstützung verschwand zur gleichen Zeit, als sie die CSP-Funktion implementierten.

Danke, das ist interessant. Ich bin mir nicht sicher, ob die beiden verwandt sind, aber wer weiß – das Github-Team hat nie öffentlich darüber gesprochen, warum sie MathJax entfernt haben. Es wäre bedauerlich, wenn etwas, das eigentlich kein Problem für ihre Einrichtung ist, der Grund gewesen wäre.

+1 für die Einhaltung von CSP.

+1

Ich habe diesen Thread gelesen und fand ihn sehr informativ und ziemlich unvoreingenommen. Ich werde meine Behauptung aufstellen, dass sie [github] so etwas wie exec, CSP in Sachen Sicherheit verhindern und es nicht zulassen würden.

Abgesehen davon, dass ich von diesem Codebeispiel und Ihrer mythischen Computergeschichte vergangener Versionen verwirrt bin, finde ich es dennoch sehr interessant und vertrete die Position, dass ein Feature für seine weitere Verwendung verfügbar gemacht werden sollte, obwohl es das Glückliche nicht beeinträchtigen sollte Pfad der Verwendung von MathJAX in der sicherheitsrelevanten Welt.

Übrigens habe ich dem Github-Support per E-Mail mitgeteilt, warum sie MathJax fallen gelassen haben. Hier ist die Antwort:

CSP war einer der Gründe. Andere Gründe waren Leistungsprobleme und harte Wartung. Wir könnten in Betracht ziehen, es wieder hinzuzufügen, wenn wir die Gründe beseitigt haben, die uns dazu veranlasst haben, es zu entfernen, aber das kann ich nicht versprechen.

Danke @ketch , das ist gut zu wissen.

@dpvc sollen wir das zum nächsten Meilenstein hinzufügen?

:+1:

@pkra , ich hatte vor, es hinzuzufügen. War zahlenmäßig nur noch nicht so weit unten in der Liste.

@dpvc richtig. Ich habe mich hauptsächlich gefragt, ob die Behebung dieses Problems erhebliche Änderungen erfordern würde (insbesondere bei Inline-Konfigurationen), dh einen Versionssprung erzwingen würde.

Die Änderungen, die wir vorgenommen haben, um die Konfiguration über die MathJax-Variable zu ermöglichen, sollten es ermöglichen, sie ohne Sprung einzufügen. Ich bin mir ziemlich sicher, dass ich es mit Abwärtskompatibilität tun kann und ohne eine separate "sichere" Version von MathJax.js erstellen zu müssen. Natürlich könnte während der Entwicklung etwas auftauchen, das einen Schraubenschlüssel in die Arbeit werfen würde; Nichts davon ist noch geschrieben oder getestet.

+1, um MathJax sicher zu machen. Schade, dass man diese schöne Bibliothek aufgrund von Sicherheitsbedenken nicht in der Produktion verwenden kann.

Irgendwelche Fortschritte zu diesem Thema? Ich versuche, MathJax programmatisch in Seiten mit einer Chrome-Erweiterung zu injizieren, und ich stoße, wenn nicht auf eine Mauer, so doch auf eine anständig solide Mauer. Wie in emichael/textthings#4 beschrieben, ist mein größtes Problem jetzt mit MathJax.js:265 . Die Anrufe konnte ich damit eliminieren

new Function()

ziemlich einfach, indem ich sie wie oben beschrieben in Closures umwandele, aber ich habe keine Ahnung, wie ich mit eval oder einem Inline-Skript umgehen soll.

BEARBEITEN: Am Ende habe ich dem Benutzer die Option gegeben, dem CSP unsafe-eval und unsafe-inline hinzuzufügen, aber eine langfristige Lösung, um MathJax zu einem sicheren CSP zu bringen, wäre schön. :+1:

@emichael , wir planen, die Änderungen in die nächste Version aufzunehmen (geplant für nächsten Monat), aber ich habe sie noch nicht vorgenommen. Ein Grund dafür ist, dass ich nicht untersucht habe, wie Sie dies tatsächlich testen (wie Sie die Umgebung einrichten, die dies erfordert). Wenn Sie mir einen Vorschlag machen könnten, wo ich suchen soll oder was eine minimale Testumgebung sein könnte, wäre das hilfreich.

Tritt der Fehler zu eval auch zur Laufzeit oder zur Kompilierzeit auf? Das heißt, tritt es auf, wenn MathJax.js einfach einen eval-Aufruf enthält, auch wenn es nie verwendet wird, oder tritt es nur auf, wenn eval tatsächlich versucht wird? Meine Lektüre der Spezifikation legt nahe, dass es sich um einen Laufzeitfehler handeln sollte, was die Dinge für mich verbessern würde, aber ich dachte, Sie kennen die Antwort vielleicht.

Wenn Sie einen Testserver haben, können Sie einfach Content-Security-Policy in den Antwortheadern festlegen. Stellen Sie einfach sicher, dass script-src nicht 'unsafe-eval' oder 'unsafe-inline' enthält (GitHub selbst ist ein gutes Beispiel). Wenn Sie dies nicht tun, können Sie eine sehr minimale Chrome-Erweiterung verwenden, um die Header selbst einzufügen.

Es ist ein Laufzeitfehler.

Danke. Ich sehe was ich tun kann.

Der eval-Befehl wird nur verwendet, um die Inline-Konfigurationsblöcke zu verarbeiten (und es gibt einen ersten, um zu testen, wie globale Variablen in diesem Fall behandelt werden). Die anfängliche kann aufgeschoben werden, bis eine Inline-Konfiguration verwendet wird, und wenn Sie die Verwendung einer Inline-Konfiguration vermeiden, sollte dies erledigt sein. In v2.3 haben wir eine neue Methode zur Inline-Konfiguration ohne Evaluierung hinzugefügt (in Vorbereitung auf die Lösung dieses Problems), sodass Sie die MathJax-Konfiguration weiterhin in die HTML-Dateien einfügen können, ohne den Evaluierungsaufruf auszulösen.

OK, ich habe einen Patch erstellt, der die Aufrufe new Function() und eval() entfernt. Es basiert auf dem neuesten Entwicklungszweig, aber die in f220993 aufgeführten Änderungen sollten auch an der Master-Kopie von MathJax.js vorgenommen werden können, falls dies erforderlich ist. Sie müssen Inline-Stile zulassen (daran führt wirklich kein Weg vorbei). Es gibt auch einen Font-Verweis auf about:blank , damit MathJax die Reaktion auf einen fehlenden Font testen kann (ohne einen Netzwerkzugriff vornehmen zu müssen), also sollten Sie about: zu font-src hinzufügen

Schön! Ich kann verstehen, warum Sie auf jeden Fall 'unsafe-inline' für Stile brauchen.

Was die script-src 'unsafe-inline' -Berechtigung betrifft, so sind Skripte, wenn ich Sie richtig verstehe, immer nur dann eingebettet, wenn der Benutzer zunächst eine Inline-MathJax-Konfiguration enthält. Das wäre in Ordnung, da alles auch ohne 'unsafe-inline' in script-src funktionieren könnte. Es sollte jedoch in den Dokumenten erwähnt werden.

Ihr Verständnis von Inline-Skripten ist richtig. Sie benötigen script-src 'unsafe-inline' nicht, es sei denn, Sie verwenden Inline-Konfigurationsblöcke, die Sie nicht verwenden müssen. Sie können entweder eine lokale MathJax-Konfigurationsdatei verwenden (hinzugefügt zu config= ) oder Sie können eine normale Skriptdatei verwenden, die die Variable MathJax auf ein Objekt setzt, das Sie normalerweise an MathJax.Hub.Config() übergeben würden

var MathJax = {
  tex2jax: {
    inlineMath: [['$','$'],['\\(','\\)']],
    procesEscapes: true
  }
};

in eine Datei namens mathjax-config.js und dann

<script src="mathjax-config.js"></script>
<script src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML"></script>

Ich hoffe, dass das Ihren Anforderungen gerecht wird.

Das tut es in der Tat. Danke für die schnelle Lösung!!

Einige hier würden sagen, dass es nicht so schnell ging (das Problem ist seit zwei Jahren offen!), aber ich hatte es für die nächste Veröffentlichung markiert und war sowieso gerade dabei, also kam Ihr Kommentar die passende Zeit.

=> Zusammengeführt.

hat also schon jemand github gebeten, mathjax zuzulassen? Es ist immer noch nicht möglich, eine Dotjs-Datei zu schreiben, mit der ich Tex in Github-Probleme schreiben kann, um mit Mathjax zu rendern ...

(Das Beispiel hier - http://stackoverflow.com/questions/16889421/how-to-insert-javascript-to-enable-mathjax-on-github-wiki-pages - schlägt fehl.)

Hallo,

Ich hoste derzeit eine Jekyll-Site auf GitHub-Seiten und folge diesem Artikel und habe Folgendes zu meiner Include-Datei hinzugefügt:

<script type="text/javascript"
  src="//cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>

Was mit https oder http funktionieren soll. Wenn ich jedoch mein Blog in einem Browser mit https überall lade, sieht es durcheinander aus, bis Sie darauf klicken, um unsicheres Skript zuzulassen. Wie kann ich das beheben?

@silky nichts spezifisches AFAWK. Clientseitig ist das unwahrscheinlich, denke ich, aber MathJax-node könnte eine produktive Alternative bieten.

@diego898 Allgemeine Fragen passen besser zu http://groups.google.com/forum/#!forum/mathjax -users; Fügen Sie immer einen Link zu einer Live-Seite, Browser- und Betriebssystemspezifikationen usw. hinzu. Danke.

@pkra Ich verstehe, ich war mir nur nicht sicher, ob es sich um einen Fehler im Zusammenhang mit diesem Problem oder um ein Konfigurationsproblem meinerseits handelt

@diego898 kein Problem. Was Sie beschreiben, klingt nicht so, als ob es mit diesem Problem zusammenhängt.

Ich sehe dieses Problem immer noch. Siehe https://github.com/mathjax/MathJax/issues/1988.

@kaushalmodi , siehe meinen Kommentar oben zur Vermeidung des Problems oder meinen Kommentar zu dem Problem, auf das Sie verlinken. Sie müssen die Konfiguration von MathJax ändern, wenn Sie einen CSP verwenden, der die Skriptausführung einschränkt.

Wurde (2) im ursprünglichen Problem jemals gelöst? Es scheint, dass mathjax v3 immer noch eingefügt wird

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen