Teil 3 – Reale Beispiele und Auswirkungen von Prototype Pollution

Warum dieser Teil wichtig ist

Bis jetzt haben wir uns angeschaut, wie Prototype Pollution technisch funktioniert: Angreifer nutzen Schlüssel wie __proto__ oder constructor.prototype, um den Prototypen von Objekten zu manipulieren.
Doch was heißt das praktisch? Welche Schäden entstehen dadurch in echten Anwendungen?
In diesem Teil gehen wir Schritt für Schritt durch reale Szenarien, Vorfälle und Bug-Bounty-Reports.

---

1. Prüfungen werden ausgetrickst

Einer der häufigsten und gefährlichsten Effekte: Sicherheitsprüfungen werden unbemerkt umgangen.

Beispiel: Admin-Prüfung

Stell dir eine Web-App vor, die prüft, ob ein Nutzer Admin ist:

function isAdmin(user) {
  return !!user.isAdmin;
}

Entwickler gehen davon aus: Nur wenn user.isAdmin explizit gesetzt ist, bekommt man Zugriff auf Admin-Funktionen.

Doch durch Prototype Pollution kann ein Angreifer erreichen, dass jedes Objekt automatisch isAdmin = true hat:

Object.prototype.isAdmin = true;

console.log(isAdmin({ name: "Alice" })); // true

Ergebnis: Plötzlich hat jeder Nutzer Admin-Rechte – selbst Gäste ohne Account.

Reale Fälle

Mehrere Bug-Bounty-Reports zeigen genau diesen Effekt. Angreifer konnten Admin-Panels betreten oder privilegierte Aktionen ausführen, indem sie den Prototypen „vergifteten“.

---

2. Feature-Toggles und Flags

Viele Anwendungen steuern Funktionen über Flags:

if (user.betaEnabled) {
  showBetaFeature();
}

Ein Angreifer polluted den Prototypen:

Object.prototype.betaEnabled = true;

Ergebnis: Jeder Nutzer sieht die Beta-Funktion – selbst wenn sie nur für interne Tester gedacht war.

Warum das gefährlich ist

• Unfertige Features können ungewollt live gehen.
• Interne oder kostenpflichtige Funktionen werden für alle freigeschaltet.
• Sicherheitsfunktionen, die eigentlich deaktiviert sind, könnten aktiviert oder manipuliert werden.

---

3. Denial of Service (DoS)

Prototype Pollution kann auch zum Absturz von Anwendungen führen.

Beispiel: toString überschreiben

Viele Libraries nutzen intern die Methode toString().

Ein Angreifer könnte setzen:

Object.prototype.toString = null;

Ab jetzt wirft jeder Aufruf von obj.toString() einen Fehler.

Folge:

• Logging-Systeme brechen zusammen.
• Serialisierungen schlagen fehl.
• Ganze Anwendungen crashen.

Reale Beobachtung

Forscher haben gezeigt, dass durch Pollution von Kernmethoden wie hasOwnProperty, valueOf oder toString ganze Frameworks wie Express oder Lodash in den Fehler laufen können.

---

4. Konfigurationsvergiftung

Ein besonders spannendes Szenario ist die Konfigurationsvergiftung.
Viele Anwendungen laden Konfigurationswerte so:

const defaults = { debug: false, locale: "de" };
const userInput = req.body; // JSON aus Anfrage
const config = deepMerge(defaults, userInput);

Wenn der Angreifer userInput so schickt:

{
  "constructor": {
    "prototype": {
      "debug": true
    }
  }
}

Dann landet debug = true plötzlich im Prototyp.

Folgen:

• Debug-Logs mit sensiblen Daten werden aktiviert.
• Zusätzliche Fehlerausgaben geben Angreifern mehr Infos.
• Sicherheitsmechanismen, die von Konfigurationsflags abhängen, können deaktiviert werden.

---

5. E-Commerce und Gutscheine

Prototype Pollution kann auch Geschäftslogik angreifen.
Beispiel:
Ein Shop prüft, ob ein Gutschein schon eingelöst wurde:

if (!order.usedCoupon) {
  applyDiscount();
  order.usedCoupon = true;
}

Angreifer polluted den Prototypen:

Object.prototype.usedCoupon = false;

Ergebnis: Jede Bestellung denkt, der Gutschein sei noch nicht benutzt – unendliche Rabatte.

---

6. Kombination mit anderen Schwachstellen

Prototype Pollution ist allein schon gefährlich.
Aber in Kombination mit anderen Schwachstellen wird es richtig brenzlig.

Mit XSS (Cross-Site Scripting)

• Pollution setzt ein Flag wie escapeHTML = false.
• Sicherheitsmechanismen zum Filtern von Eingaben greifen nicht mehr.
• Ergebnis: Eingaben werden unescaped ausgegeben → XSS.

Mit RCE (Remote Code Execution)

Manche Libraries nutzen dynamische Eigenschaften in gefährlichen Kontexten.
Wenn Angreifer den Prototyp so manipulieren, dass bestimmte Optionen aktiv werden, kann das zu Code-Ausführung führen.

---

7. Reale Bug-Bounty-Reports

a) Lodash (2019)

Eine der bekanntesten Libraries in der JavaScript-Welt war verwundbar.
Angreifer konnten über merge oder defaultsDeep den Prototypen manipulieren.

b) jQuery (2019)

Auch jQuery war in bestimmten Versionen anfällig, wenn Objekte aus HTML-Attributen erzeugt wurden.

c) Node.js-Module

Immer wieder tauchen Berichte auf, dass populäre Node-Module wie hoek, mixin-deep oder defaults-deep anfällig waren. Viele dieser Libraries werden millionenfach heruntergeladen.

---

8. Warum Entwickler es übersehen

• Es wirkt unsichtbar: Pollution verändert den Prototyp – aber normale Funktionstests merken davon oft nichts.
• Scanner erkennen es selten: Standard-Schwachstellenscanner testen nicht auf „geerbte Eigenschaften“.
• Es ist ungewöhnlich: Viele Entwickler wissen gar nicht, dass __proto__ oder constructor.prototype so gefährlich sind.

---

9. Analogie: Stadt mit Hauptwasserleitung

Stell dir eine Stadt vor:

• Jedes Haus hat einen eigenen Wasserhahn (eigene Eigenschaften).
• Alle Häuser hängen am gleichen Hauptrohr (Prototyp).

Wenn jemand das Hauptrohr verunreinigt, kommt verschmutztes Wasser in jedes Haus – egal, wie sauber die eigenen Leitungen sind.

So ist es mit Prototype Pollution: Ein Angriff wirkt prozessweit.

---

Was du bis hier mitnehmen solltest

• Prototype Pollution hat reale und sehr gefährliche Auswirkungen.
• Häufige Folgen:
  • Prüfungen werden umgangen.
  • Flags und Feature-Toggles werden manipuliert.
  • Anwendungen stürzen durch DoS ab.
  • Konfigurationen werden vergiftet.
• Viele bekannte Libraries waren in der Vergangenheit anfällig.
• Das Problem ist schwer zu entdecken und wird von Entwicklern oft unterschätzt.