Warum JSON.stringify nicht so harmlos ist, wie es scheint
Entwickler verwenden JSON. stringify täglich, um Daten zu serialisieren, Objekte zu versenden, Status in Dateien zu speichern oder Konfigurationen dauerhaft zu speichern. Dieser scheinbar harmlose Aufruf von JSON. stringify kann jedoch zu einer unsicheren Deserialisierung führen, wenn die Daten später ohne Validierung rehydriert werden.
Das Problem ist nicht JSON. stringify selbst, sondern wie wir es missbrauchen. Wenn Sie komplexe Objekte serialisieren (insbesondere mit Prototypen oder Klasseninstanzen) und sie später blind deserialisieren mit JSON.parsen, besteht die Gefahr, dass in Ihrer Anwendung schädliche Nutzdaten zum Leben erweckt werden.
In JavaScript kann man leicht davon ausgehen, dass das Serialisierte sicher ist, weil es „nur JSON.“ Aber JSON ist Daten, keine Logik. Wenn Angreifer diese Daten kontrollieren, können sie Vertrauensgrenzen in Ihrem Code ausnutzen. Hier beginnt die unsichere Deserialisierung.
Häufige Entwicklerfehler, die eine unsichere Deserialisierung ermöglichen
Unsichere Deserialisierung entsteht meist durch Gewohnheiten, die bei Code-Reviews harmlos aussehen. Aber wenn JSON. stringify unvorsichtig verwendet wird, die Angriffsfläche vergrößert sich.
Unsichere Vorgehensweise: Serialisierung nicht validierter Benutzereingaben
⚠️Warnung: Dieses Muster serialisiert vom Angreifer kontrollierte Eingaben ohne jegliche Validierung. Dies kann zu einer unsicheren Deserialisierung führen, wenn die Daten später als vertrauenswürdig eingestuft werden.
// Node.js example
const userData = req.body; // attacker-controlled
fs.writeFileSync('userdata.json', JSON.stringify(userData));
⚠️Warnung: Durch die Deserialisierung derselben Daten ohne Validierung kann die Nutzlast erneut in Ihre App eingeführt werden.
const input = JSON.parse(fs.readFileSync('userdata.json'));
doSomething(input); // Trusting it blindly
Gefährliches Muster: Wiederverwendung von JSON über Vertrauensgrenzen hinweg
Serialisiertes JSON, das in einem Dienst (Entwicklungsumgebung) erstellt wurde, wird ohne Validierung in einem anderen Dienst (Produktionsumgebung) wiederverwendet. Dies geschieht häufig in internen Tools oder Microservices.
Python-Beispiel für stilles Risiko:
⚠️Warnung: Sowohl die Serialisierungs- als auch die Deserialisierungsschritte unten verarbeiten potenziell nicht vertrauenswürdige Daten ohne Validierung.
import json
def save_user_input(data):
with open('input.json', 'w') as f:
f.write(json.dumps(data))
def process_input():
with open('input.json') as f:
data = json.loads(f.read())
execute_logic(data) # Dangerous if data structure is assumed
Beide Beispiele serialisieren und deserialisieren benutzergesteuerte Daten ohne Schemaerzwingung. Dies ist ein Nährboden für unsichere Deserialisierungs-Exploits, die durch unvorsichtige JSON-Stringify-Nutzung ausgelöst werden.
Reale Risiken in Pipelines: Vom Code zum CI/CD Deserialisierungsflüsse
Betrachten Sie dieses Verhalten nun in einer pipeline. Wenn JSON. stringify missbraucht wird innerhalb CI/CD Workflows setzen Sie Ihren Build-Prozess unsicheren Deserialisierungsrisiken aus. Dies geschieht häufig bei Artefakt-Metadaten, Testvorrichtungen und Konfigurations-Snapshots.
gemeinsam CI/CD Fallstricke:
- Unsichere Artefaktgenerierung: Build-Artefakte enthalten serialisierte Objekte, die ohne Validierung in mehreren Jobs wiederverwendet werden.
- Serialisierte Umgebungsvariablen: Teams speichern Umgebungsvariablen als serialisiertes JSON und verwenden sie über Schritte oder sogar Projekte hinweg wieder.
- Eingeschleuste Testdaten: Deserialisierte Testdaten von nicht vertrauenswürdigen commits oder Zweige, die ohne Typprüfung ausgeführt werden.
Diese Muster machen es Angreifern leicht, Nutzdaten in vertrauenswürdige pipelines verwendet manipulierte JSON-Stringify-Logik.
⚠️Warnung:Dieser Workflow übergibt serialisierte Daten ohne Validierung. Wenn test-runner.js die Eingabe nicht validiert, besteht das Risiko einer unsicheren Deserialisierung.
# YAML example in GitHub Actions
steps:
- name: Load test data
run: |
echo '${{ secrets.TEST_JSON }}' > test.json
node test-runner.js test.jsonIf test-runner.js Lädt und analysiert JSON ohne Validierung, kann dies eine unsichere Deserialisierung auslösen.
Sichern von JSON. stringify mit Validierung und sicherem Parsen
Die Lösung besteht nicht darin, JSON. stringify zu vermeiden, sondern es sorgfältig zu verwenden und Sicherheitsüberprüfungen konsequent durchzuführen. Richtig gehandhabt ist es sicher, aber in modernen pipelines, Annahmen brechen schnell.
DevSecOps-Praktiken zur Sicherung JSON.stringify:
- Verwenden Sie JSON-Schemas, um serialisierte und deserialisierte Daten zu validieren.
- Erzwingen Sie eine strikte Typisierung und vermeiden Sie Duck-Typing oder Annahmen über Objektformen.
- Verwenden Sie sichere Analysebibliotheken, die Schemadurchsetzung oder Typschutz unterstützen.
- Behandeln Sie serialisierte Daten als nicht vertrauenswürdig, auch wenn sie aus einem vertrauenswürdigen Repo stammen.
- Instrument pipelines, um riskante JSON.stringify-Muster frühzeitig zu erkennen.
Best Practice: Dieses Beispiel verwendet die JSON-Schemavalidierung, um unsichere Deserialisierung zu verhindern. Beispiel mit AJV in Node.js:
const Ajv = require("ajv");
const ajv = new Ajv();
const schema = { type: "object", properties: { id: { type: "number" } }, required: ["id"] };
const validate = ajv.compile(schema);
const input = JSON.parse(fs.readFileSync('input.json'));
if (!validate(input)) throw new Error("Invalid input");
Sichere Deserialisierung bedeutet Validierung bevor Vertrauensvoll. Verlassen Sie sich nicht auf JSON. Stringify verwendet die Standardeinstellungen, um Ihre Sicherheit zu gewährleisten. Definieren Sie, wie „sicher“ aussieht.
Erkennen von Serialisierungsrisiken mit Xygeni
Durch manuelles Auditing lassen sich nur begrenzte Daten erfassen. Xygeni bietet Einblick in die Verwendung von JSON.stringify in Ihrer Codebasis und pipelines.
Was Xygeni bewirkt:
- Traces (Spuren) JSON.stringify Nutzung vom Quellcode bis zur Bereitstellung.
- Erkennt unsichere Deserialisierungsflüsse, insbesondere über Microservices hinweg und pipeline Stufen.
- Kennzeichnet die Serialisierung unsicherer Daten wie Umgebungsvariablen, Benutzereingaben oder Artefakte.
- Warnmeldungen zu Musterabweichungen, die anzeigen, wenn serialisierte Daten ihre Form ändern oder Vertrauensgrenzen überschreiten.
Diese Art der Sichtbarkeit ist entscheidend, wenn es um die Risiken unsicherer Deserialisierung geht, die durch JSON.stringify entstehen, insbesondere in CI/CD Systeme, in denen serialisierte Daten schnell und leise übertragen werden.
JSON sichern. stringify: Ihr Schutzschild gegen unsichere Deserialisierung
JSON. stringify ist an sich nicht unsicher. Bei unvorsichtiger Verwendung wird es jedoch zum Tor für eine unsichere Deserialisierung.
Wenn Sie ein Entwickler sind, der mit JSON arbeitet:
- Überprüfen Sie Ihre Nutzung über alle Dienste hinweg. pipelines und Werkzeuge.
- Behandeln Sie deserialisierte Daten als nicht vertrauenswürdig.
- Wenden Sie Schemavalidierung an, erzwingen Sie Typen und integrieren Sie Sicherheit in Ihre CI/CD.
Und hören Sie nicht bei Best Practices auf, sondern nutzen Sie Xygeni, um unsichere Deserialisierungsrisiken aufzuspüren, zu erkennen und zu stoppen, bevor sie in die Produktion gelangen. Serialisierung ist nicht neutral. Nutzen Sie JSON. stringify zu sichern.
