Waarom JSON.stringify niet zo onschadelijk is als het lijkt
Ontwikkelaars gebruiken JSON.stringify dagelijks om data te serialiseren, objecten via de kabel te versturen, de status in bestanden op te slaan of configuraties te behouden. Maar die ogenschijnlijk onschuldige aanroep van JSON.stringify kan onveilige deserialisatie veroorzaken als de data later zonder validatie wordt gerehydrateerd.
Het probleem is niet JSON.stringify zelf, maar hoe we het misbruiken. Wanneer je complexe objecten serialiseert (vooral met prototypes of klasse-instanties) en ze later blindelings deserialiseert met behulp van JSON. parsen, loopt u het risico dat er schadelijke payloads in uw applicatie terechtkomen.
In JavaScript is het gemakkelijk om aan te nemen dat wat geserialiseerd is veilig is omdat het 'gewoon' is JSONMaar JSON draait om data, niet om logica. Als aanvallers die data controleren, kunnen ze vertrouwensgrenzen in je code misbruiken. Dit is waar onveilige deserialisatie begint.
Veelvoorkomende fouten van ontwikkelaars die onveilige deserialisatie mogelijk maken
Onveilige deserialisatie komt meestal voort uit gewoonten die er in codereviews onschuldig uitzien. Maar wanneer JSON.stringify onzorgvuldig wordt gebruikt, het aanvalsoppervlak breidt zich uit.
Onveilige praktijk: serialiseren van niet-gevalideerde gebruikersinvoer
⚠️Waarschuwing: Dit patroon serialiseert door aanvallers gecontroleerde invoer zonder enige validatie. Dit kan leiden tot onveilige deserialisatie als de gegevens later worden vertrouwd.
// Node.js example const userData = req.body; // attacker-controlled fs.writeFileSync('userdata.json', JSON.stringify(userData)); ⚠️Waarschuwing: Als u dezelfde gegevens deserialiseert zonder validatie, kan de payload opnieuw in uw app worden geïntroduceerd.
const input = JSON.parse(fs.readFileSync('userdata.json')); doSomething(input); // Trusting it blindly Gevaarlijk patroon: JSON hergebruiken over vertrouwensgrenzen heen
Geserialiseerde JSON die in de ene service (dev-omgeving) is gemaakt, wordt zonder validatie hergebruikt in een andere (prod). Dit gebeurt vaak in interne tools of microservices.
Python-voorbeeld van stil risico:
⚠️Waarschuwing: Zowel de onderstaande serialisatie- als deserialisatiestappen verwerken mogelijk niet-vertrouwde gegevens zonder validatie.
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 voorbeelden serialiseren en deserialiseren door de gebruiker beheerde data zonder schema-afdwinging. Dit is een broedplaats voor onveilige deserialisatie-exploits die worden geactiveerd door onzorgvuldig JSON.stringify-gebruik.
Echte risico's in Pipelines: Van code naar CI/CD Deserialisatiestromen
Neem dat gedrag nu eens in een pipeline. Wanneer JSON.stringify verkeerd wordt gebruikt binnen CI/CD Workflows stellen uw buildproces bloot aan onveilige deserialisatierisico's. Dit gebeurt vaak met artefactmetadata, testfixtures en configuratiesnapshots.
Veelgestelde CI/CD valkuilen:
- Onveilige artefactgeneratie: Bouwartefacten bevatten geserialiseerde objecten die zonder validatie opnieuw in taken worden gebruikt.
- Geserialiseerde omgevingsvariabelen: teams slaan omgevingsvariabelen op als geserialiseerde JSON en hergebruiken deze in verschillende stappen of zelfs projecten.
- Geïnjecteerde testgegevens: Gedeserialiseerde testgegevens van niet-vertrouwde commits of branches uitgevoerd zonder typecontrole.
Deze patronen maken het voor aanvallers gemakkelijk om payloads in vertrouwde bronnen te injecteren. pipelines met behulp van gemanipuleerde JSON stringify logica.
⚠️Waarschuwing:Deze workflow geeft geserialiseerde gegevens door zonder validatie. Als test-runner.js de invoer niet valideert, bestaat het risico op onveilige deserialisatie.
# 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 laadt en parseert JSON zonder validatie, wat een onveilige deserialisatie kan veroorzaken.
JSON.stringify beveiligen met validatie en veilig parsen
De oplossing is niet om JSON.stringify te vermijden, maar om het zorgvuldig te gebruiken en consequent beveiligingscontroles toe te passen. Mits goed gebruikt, is het veilig, maar in moderne pipelines, aannames zijn snel onjuist.
DevSecOps-praktijken voor het beveiligen JSON.stringify:
- Gebruik JSON-schema's om geserialiseerde en gedeserialiseerde gegevens te valideren.
- Pas strikte typering toe, vermijd duck-typing of aannames over de vorm van objecten.
- Gebruik veilige parsingbibliotheken die schemahandhaving of typeguards ondersteunen.
- Behandel geserialiseerde gegevens als niet-vertrouwd, zelfs als ze afkomstig zijn van een vertrouwde opslagplaats.
- Instrument pipelineom risicovolle JSON.stringify-patronen vroegtijdig te detecteren.
Best Practice: Dit voorbeeld maakt gebruik van JSON-schemavalidatie om onveilige deserialisatie te voorkomen. Voorbeeld met bijv 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"); Veilige deserialisatie betekent valideren vaardigheden Vertrouwen. Vertrouw niet op JSON. Stringify-standaardinstellingen zorgen voor uw veiligheid; definieer hoe veilig eruitziet.
Serialisatierisico's detecteren met Xygeni
Met handmatige controles kun je niet alles vaststellen. Xygeni geeft inzicht in hoe JSON.stringify in uw codebase wordt gebruikt en pipelines.
Wat Xygeni doet:
- Sporen JSON.stringify gebruik van broncode tot implementatie.
- Detecteert onveilige deserialisatiestromen, vooral in microservices en pipeline stadia.
- Markeert serialisatie van onveilige gegevens, zoals omgevingsvariabelen, gebruikersinvoer of artefacten.
- Waarschuwingen bij patroonafwijkingen, die aangeven wanneer geserialiseerde gegevens van vorm veranderen of vertrouwensgrenzen overschrijden.
Dit soort zichtbaarheid is cruciaal bij het omgaan met onveilige deserialisatierisico's die worden geïntroduceerd door JSON.stringify, vooral in CI/CD systemen waarin geserialiseerde gegevens snel en stil worden verplaatst.
JSON.stringify beveiligen: uw schild tegen onveilige deserialisatie
JSON.stringify is op zichzelf niet onveilig. Maar bij onzorgvuldig gebruik vormt het de toegangspoort tot onveilige deserialisatie.
Als u een ontwikkelaar bent die met JSON werkt:
- Controleer uw gebruik ervan in alle services, pipelines en gereedschappen.
- Behandel gedeserialiseerde gegevens als niet-vertrouwd.
- Pas schemavalidatie toe, dwing typen af en integreer beveiliging in uw CI/CD.
En blijf niet bij de best practices, gebruik Xygeni om onveilige deserialisatierisico's op te sporen, te detecteren en te stoppen voordat ze in de productie terechtkomen. Serialisatie is niet neutraal. Maak er gebruik van. JSON.stringify veilig.






