Dlaczego JSON.stringify nie jest tak nieszkodliwy, jak się wydaje
Programiści używają JSON.stringify na co dzień do serializacji danych, przesyłania obiektów przez sieć, przechowywania stanu w plikach lub utrwalania konfiguracji. Jednak to pozornie niegroźne wywołanie JSON.stringify może prowadzić do niebezpiecznej deserializacji, jeśli dane zostaną później ponownie uwodnione bez walidacji.
Problemem nie jest sam JSON. stringify, ale sposób, w jaki go nadużywamy. Kiedy serializujesz złożone obiekty (zwłaszcza prototypy lub instancje klas), a następnie bezmyślnie deserializujesz je za pomocą JSON.parse, ryzykujesz wprowadzeniem do swojej aplikacji złośliwych ładunków.
W JavaScript łatwo założyć, że to, co jest serializowane, jest bezpieczne, ponieważ „po prostu JSON”. Ale JSON to dane, a nie logika. Jeśli atakujący przejmą kontrolę nad tymi danymi, mogą wykorzystać granice zaufania w kodzie. To właśnie tutaj zaczyna się niebezpieczna deserializacja.
Typowe błędy programistów, które umożliwiają niebezpieczną deserializację
Niebezpieczna deserializacja zazwyczaj wynika z nawyków, które w recenzjach kodu wydają się nieszkodliwe. Ale gdy JSON.stringify jest używany nieostrożnie, powierzchnia ataku się rozszerza.
Niebezpieczna praktyka: Serializowanie niezweryfikowanych danych wejściowych użytkownika
⚠️Ostrzeżenie: Ten wzorzec serializuje dane wejściowe kontrolowane przez atakującego bez żadnej walidacji. Może to prowadzić do niebezpiecznej deserializacji, jeśli dane zostaną później uznane za zaufane.
// Node.js example
const userData = req.body; // attacker-controlled
fs.writeFileSync('userdata.json', JSON.stringify(userData));
⚠️Ostrzeżenie: Deserializacja tych samych danych bez weryfikacji może spowodować ponowne wprowadzenie ładunku do aplikacji.
const input = JSON.parse(fs.readFileSync('userdata.json'));
doSomething(input); // Trusting it blindly
Niebezpieczny wzorzec: ponowne wykorzystywanie JSON-a w granicach zaufania
Zserializowany kod JSON utworzony w jednej usłudze (środowisku deweloperskim) jest ponownie wykorzystywany w innej (środowisku produkcyjnym) bez walidacji. Często zdarza się to w narzędziach wewnętrznych lub mikrousługach.
Przykład cichego ryzyka w Pythonie:
⚠️Ostrzeżenie: Poniższe kroki serializacji i deserializacji dotyczą danych potencjalnie niepewnych, które nie są sprawdzane.
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
Oba przykłady serializują i deserializują dane kontrolowane przez użytkownika bez wymuszania schematu. To sprzyjające zagrożeniom dla niebezpiecznych deserializacji, wyzwalanych przez nieostrożne użycie stringify w formacie JSON.
Prawdziwe zagrożenia w Pipelines: Od kodu do CI/CD Przepływy deserializacji
Teraz rozważmy to zachowanie w szerszym kontekście. pipeline. Gdy JSON.stringify jest niewłaściwie używany w CI/CD W przypadku przepływów pracy narażasz proces kompilacji na ryzyko związane z niebezpieczną deserializacją. Często zdarza się to w przypadku metadanych artefaktów, wyposażenia testowego i migawek konfiguracji.
wspólny CI/CD pułapki:
- Niezabezpieczone generowanie artefaktów: Artefakty kompilacji obejmują obiekty serializowane, które są ponownie wykorzystywane w różnych zadaniach bez sprawdzania poprawności.
- Serializowane zmienne środowiskowe: Zespoły przechowują zmienne środowiskowe jako serializowany plik JSON i wykorzystują je ponownie w różnych krokach, a nawet projektach.
- Wstrzyknięte dane testowe: Deserializowane dane testowe z niezaufanych źródeł commits lub gałęzie wykonywane bez sprawdzania typu.
Te wzorce ułatwiają atakującym wstrzykiwanie ładunków do zaufanych pipelines wykorzystując zmanipulowaną logikę stringify JSON.
⚠️Ostrzeżenie:Ten przepływ pracy przekazuje zserializowane dane bez walidacji. Jeśli plik test-runner.js nie zweryfikuje danych wejściowych, istnieje ryzyko niebezpiecznej deserializacji.
# YAML example in GitHub Actions
steps:
- name: Load test data
run: |
echo '${{ secrets.TEST_JSON }}' > test.json
node test-runner.js test.json
If test-runner.js ładuje i analizuje dane JSON bez walidacji, może to spowodować niebezpieczną deserializację.
Zabezpieczanie JSON.stringify z walidacją i bezpieczną analizą
Rozwiązaniem nie jest unikanie JSON.stringify, ale ostrożne korzystanie z niego i konsekwentne stosowanie zabezpieczeń. Prawidłowo obsługiwany jest bezpieczny, ale w nowoczesnych… pipelines, założenia szybko ulegają zniszczeniu.
Praktyki DevSecOps zapewniające bezpieczeństwo JSON.stringify:
- Użyj schematów JSON do walidacji danych serializowanych i deserializowanych.
- Stosuj ścisłe przestrzeganie zasad pisania, unikaj pisania bezmyślnego i przyjmowania założeń na temat kształtów obiektów.
- Użyj bezpiecznych bibliotek parsujących, które obsługują egzekwowanie schematu lub ochronę typów.
- Dane serializowane należy traktować jako niezaufane, nawet jeśli pochodzą z zaufanego repozytorium.
- Instrument pipelineaby wcześnie wykryć ryzykowne wzorce JSON.stringify.
Najlepsza praktyka: W tym przykładzie użyto walidacji schematu JSON, aby zapobiec niebezpiecznej deserializacji. Przykład użycia przym w 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");
Bezpieczna deserializacja oznacza walidację zanim Zaufaj. Nie polegaj na JSON-ie. Domyślne ustawienia stringify zapewnią Ci bezpieczeństwo; zdefiniuj, jak wygląda bezpieczeństwo.
Wykrywanie ryzyka serializacji za pomocą Xygeni
Ręczne audyty nie wykryją zbyt wielu rzeczy. Xygeni zapewnia wgląd w sposób wykorzystania JSON.stringify w całej bazie kodu i pipelines.
Czym zajmuje się Xygeni:
- Ślady JSON.stringify wykorzystanie od kodu źródłowego do wdrożenia.
- Wykrywa niebezpieczne przepływy deserializacji, szczególnie w obrębie mikrousług i pipeline gradacja.
- Flagi serializacji niebezpiecznych danych, takich jak zmienne środowiskowe, dane wprowadzone przez użytkownika lub artefakty.
- Alerty dotyczące odchyleń od wzorca, pokazujące kiedy zserializowane dane zmieniają kształt lub przekraczają granice zaufania.
Ten rodzaj widoczności jest krytyczny w przypadku radzenia sobie z ryzykiem niebezpiecznej deserializacji wprowadzanym przez JSON.stringify, szczególnie w CI/CD systemy, w których zserializowane dane przemieszczają się szybko i cicho.
Zabezpieczanie JSON. stringify: Twój Shield Przeciwko niebezpiecznej deserializacji
JSON.stringify sam w sobie nie jest niebezpieczny. Jednak używany bez ostrożności staje się bramą do niebezpiecznej deserializacji.
Jeśli jesteś programistą pracującym z JSON:
- Przeprowadź audyt korzystania z niego w różnych usługach, pipelinei narzędzia.
- Dane deserializowane należy traktować jako niezaufane.
- Zastosuj walidację schematu, wymuszaj typy i integruj zabezpieczenia ze swoim CI/CD.
Nie zatrzymuj się na najlepszych praktykach, korzystaj z rozwiązania Xygeni, aby śledzić, wykrywać i zatrzymywać zagrożenia związane z niezabezpieczoną deserializacją, zanim pojawią się one w środowisku produkcyjnym. Serializacja nie jest neutralna. Wykorzystaj ją JSON.stringify bezpieczne.
