tc39/proposal-symbol-protoTC39-Vorschlag zur Abschwächung von Prototype Pollution
Autoren: Santiago Díaz (Google)
Befürworter: Shu-yu Guo (Google)
Stufe: 1
freeze, seal und preventExtensions
Dieser Vorschlag zielt darauf ab, eine sprachbezogene Schwachstelle namens Prototype Pollution mit einem Mechanismus zu entschärfen, der die Einfrier-Operationen ergänzt, sowie mit einem Mechanismus, der die meisten Codebasen damit kompatibel macht. Er beschreibt eine Opt-in-Funktion, die Prototypen nur noch über Reflexions-APIs zugänglich macht. Dadurch kann die Anweisung obj[key] nicht mehr auf Prototypen zugreifen. Codebasen, die mit dieser Funktion kompatibel sind, gehen bewusster mit der Verwendung von Prototypen um.
PP-Schwachstellen erlauben Angreifern, Objekte zu manipulieren, die sie zur Laufzeit nicht kontrollieren oder auf die sie keinen Zugriff haben. Dieser Mechanismus der 'spukhaften Fernwirkung' kann verwendet werden, um die Form anderer Objekte zu verändern und deren Eigenschaften zu überschreiben, wodurch Objekte zur Laufzeit verunreinigt werden.
Verunreinigte Objekte entkräften die zugrunde liegenden Annahmen von Code, der andernfalls sicher/korrekt wäre, und können zu beliebiger Codeausführung und einer Vielzahl weiterer Sicherheitsprobleme in JS-Codebasen führen. Prototype-Pollution-Fehler äußern sich häufig in Webanwendungen, betreffen aber auch Nicht-Web-JS-Laufzeiten.
Objekteigenschaften in JS sind von jedem Code beschreibbar, der auf sie verweisen kann. Wenn insbesondere viele Objekte von einer gemeinsamen Eigenschaft abhängen, kann jedes einzelne von ihnen Änderungen an allen anderen bewirken.
Eine besondere Eigenschaft von PP ist, dass es sich um einen Data-only-Angriff handelt, der Codeausführung rein durch Daten erreicht. Siehe zum Beispiel den folgenden verwundbaren Code und einen entsprechenden Exploit:
// source is attacker-controlled
function merge(target, source) {
for (let key in source) {
if (typeof source[key] === 'object') {
if(target[key] === undefined) {
target[key] = {};
}
target[key] = merge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// User input comes as a string
const userSuppliedObj = JSON.parse('{"__proto__": {"polluted": true}}');
// Trigger prototype pollution
merge({}, userSuppliedObj);
// Create a brand new object
const newObj = {};
// Has polluted property
console.log(newObj.polluted); // true
Beachten Sie, dass der Exploit die Erstellung neuer Objekte verunreinigen kann, ohne fremden Code einzuschleusen.
Aufgrund dieser besonderen Eigenschaft greifen moderne Gegenmaßnahmen gegen Codeausführungsprobleme - wie die Content Security Policy oder Trusted Types - bei PP zu kurz, da sie sich auf die Durchsetzung der Codeherkunft konzentrieren.
Hinweis: Data-only-Angriffe sind relevant für Situationen, in denen der auf der VM ausgeführte Code vertrauenswürdig ist und beliebige Codeausführung sicherheitsrelevante Auswirkungen hat.
freeze, seal und preventExtensionsBestehende Einfrier-Operationen leiden unter erheblichen Designproblemen, die eine breite Einführung unwahrscheinlich machen. Sie können für erfahrene Benutzer nützlich sein, sind aber nicht für den Einsatz durch die Mehrheit der Entwickler geeignet, die berechtigterweise erwarten, dass Prototypen veränderbar sind:
Freeze-APIs leiden unter dem Override-Fehler und weiteren Inkonsistenzen, die in bestehenden Codebasen Fehler verursachen, indem sie Werfen auslösen oder schlimmer noch, im Sloppy-Modus still fehlschlagen. Eine frühere Untersuchung des Override-Fehlers kam zu dem Schluss, dass der Override-Fehler bei ~10 % der Codebasen im Strict-Modus und bei 20 % im Sloppy-Modus ausgelöst wird. Die Untersuchung wurde kurz darauf eingestellt.
Freeze-APIs geben Entwicklern die schwere Verantwortung zu wissen, welche Prototypen eingefroren werden müssen, um eine sichere Codebasis zu erhalten – unter der Annahme, dass Entwickler Sicherheitsexperten sind. Diese APIs beschreiben das Was, aber nicht das Wie von Sicherheit. Object einzufrieren ist sicherlich nicht gut genug, da viele Exploits Array missbrauchen. Was ist mit Error, Date, Reflect oder Proxy? Oder zukünftigen eingebauten Typen? Freeze-APIs geben auf diese Fragen keine Antworten.
Freeze-APIs setzen einen stabilen Einfrierpunkt voraus: einen festen Zeitpunkt zur Laufzeit, an dem sich Prototypen beruhigt haben und eingefroren werden können. In der Praxis ist dieser Punkt volatil und ändert sich im Laufe der Zeit in Codebasen, die aktiv weiterentwickelt werden. Während man einen solchen Punkt heute in vielen Anwendungen finden kann, machen das Hinzufügen neuer Abhängigkeiten, Polyfills, Änderungen an der Codestruktur sowie leistungsstarke Funktionen wie Hot-Swapping und Entwicklerwerkzeuge Einfrierpunkte zu einem beweglichen Ziel.
Freeze-APIs können nicht die gesamte Prototypenkette schützen. In JS können Objekte zu jedem Zeitpunkt zur Prototypenkette hinzugefügt oder aus ihr entfernt werden. Um die gesamte Kette zu schützen, muss man stets daran denken, Objekte einzufrieren, die zur Kette hinzugefügt werden – ein fehleranfälliger Prozess. Wenn sie aus der Kette entfernt werden, können sie nicht wieder aufgetaut werden.
Kurz gesagt: eine Funktion, die Prototypen nur über Reflexions-APIs zugänglich macht. Wären Prototypen nicht über Eigenschaften wie __proto__ oder prototype verfügbar, wären sie keinen Data-only-Angriffen ausgesetzt.
Dies wird anhand eines Beispiels besser verständlich: Die Anweisung obj[one][two] = value ist über obj.__proto__.polluted anfällig für PP. Wenn man die Eigenschaft Object.prototype.__proto__ löscht, ist dieselbe Anweisung nicht mehr anfällig, da sie nicht den einzigen anderen Weg zu Prototypen nutzen kann, nämlich obj.constructor.prototype.polluted. Beachten Sie, dass prototype nicht gelöscht werden kann.
Dieser Vorschlag kann umgesetzt werden, indem Reflexions-APIs bereitgestellt und eine neue Opt-in-Kapselungsfunktion geschaffen werden, die Prototypeigenschaften löscht. Eine Beschreibung der einzelnen Schritte folgt.
__proto__ ist ein veralteter Eigenschaftsname, der gelöscht werden kann, aber der interne Slot dahinter kann weiterhin über Object/Reflect.getPrototypeOf gelesen und über Object/Reflect.setPrototypeOf geschrieben werden, wodurch diese Eigenschaft weiterhin für bereits laufenden Code zugänglich bleibt.