Handlebars.js: Lenker-zu-HTML-Konvertierung in 3.0.5 . defekt
{{#Optionen}}
In der obigen Lenkerdatei haben wir das Attribut durch den folgenden Code ersetzt und es funktionierte wie erwartet,
attrs: "data=#{dataContext.id.toString()} style= width:70px; "
Dies funktionierte in der Version 3.0.3 einwandfrei und wurde richtig in den folgenden Code interpretiert,
data="5336686" style=" width:70px; "
Aber als wir auf 3.0.5 aktualisiert haben, bricht der obige Code ab und gibt die folgende codierte Codeausgabe aus:
data=5339575 style=width:70px;
Soweit ich weiß, sind alle Neben- und Patchversionen abwärtskompatibel. Ich würde gerne wissen, dass wir den obigen Code überarbeiten sollten oder dies in der nächsten Nebenversion rückgängig gemacht werden könnte? Dies hat bei uns zu einem großen Produktionsproblem geführt :( Danke im Voraus!
rhariraman
Alle 5 Kommentare
Wir haben genau das gleiche Problem. In unserem Fall haben wir base64-codierte Strings, die ansonsten intakt bleiben, aber alle nachfolgenden = Zeichen werden in = .
huijar
am 21. Dez. 2018
+1, genau das gleiche Problem hier.
jlaari
am 21. Dez. 2018
Hi. Es tut mir leid, wenn diese Änderung Probleme für Sie verursacht. Es wurde über #1083 eingeführt. Ich habe es als Antwort auf #1454 veröffentlicht, das auf einen Eintrag in der Knotensicherheitsdatenbank verweist.
Aber Sie haben Recht. Die Liste der Escape-Zeichen wurde dokumentiert, daher war dies eine bahnbrechende Änderung.
Ich werde es rückgängig machen, aber ich werde auch die Meinungen der Leute einholen, die die Änderung haben wollten.
Update: Nein, ich werde es jetzt nicht rückgängig machen. Nein, es ist halb nach Mitternacht, wo ich lebe, also werde ich schlafen gehen und darüber nachdenken.
@rhariraman Übrigens: Du verwendest das fehlende "="-Escapen genau so, wie es die Schwachstelle verursachen kann (siehe https://github.com/wycats/handlebars.js/pull/1083#issuecomment-134733449)
nknapp
am 22. Dez. 2018
Der Sicherheitsfix wird in Version 3.0.6 zurückgesetzt
Gleichheitszeichen werden nicht mehr maskiert.
nknapp
am 2. Jan. 2019
@nknapp Vielen Dank :)
rhariraman
am 2. Jan. 2019
Verwandte Themen
fcpauldiaz
·
4Kommentare
amirzandi
·
7Kommentare
rizen
·
6Kommentare
asgraf
·
5Kommentare
snimavat
·
5Kommentare
Hilfreichster Kommentar
Wir haben genau das gleiche Problem. In unserem Fall haben wir base64-codierte Strings, die ansonsten intakt bleiben, aber alle nachfolgenden
=Zeichen werden in=.