Wat is NoSQL-injectie? Hoe werkt het en hoe voorkomt u het?

Wat is NoSQL-injectie?

NoSQL-injectie is een kwetsbaarheid waarmee aanvallers query's voor NoSQL-databases manipuleren door schadelijke operators, JavaScript-code of speciaal samengestelde syntaxis via niet-gevalideerde gebruikersinvoer in te voegen. De kwetsbaarheid is in de Common Weakness Enumeration (CWE) formeel geclassificeerd als CWE-943, "Onjuiste neutralisatie van speciale elementen in databasequerylogica". Ze treft databases zoals MongoDB, Redis, Cassandra en Elasticsearch, die flexibele querytalen zonder vast schema gebruiken in plaats van standaard-SQL.

Een geslaagde aanval gaat veel verder dan één gemanipuleerde query. Een aanvaller kan authenticatie volledig omzeilen, gevoelige gegevens teken voor teken ophalen, records wijzigen, denial-of-service veroorzaken of willekeurige code op de server uitvoeren. Zoals de OWASP WSTG opmerkt, "zijn de potentiële gevolgen groter dan bij traditionele SQL-injectie", omdat payloads voor NoSQL-injectie binnen een procedurele taal zoals JavaScript kunnen worden uitgevoerd, en niet alleen binnen een declaratieve querytaal.

NoSQL-databases ondersteunen inmiddels alles van inlogsystemen en chatplatforms tot webwinkelcatalogi en IoT-beheerconsoles. Door hun groeiende populariteit en het wijdverbreide misverstand dat "geen SQL ook geen injectie betekent", blijft deze kwetsbaarheid een risico. Die aanname klopt niet, en aanvallers rekenen daarop. 

Voordat we bekijken hoe NoSQL-injectie in de praktijk werkt, is het nuttig te weten hoe deze kwetsbaarheid binnen de gangbare classificatiekaders wordt ingedeeld.

OWASP-classificatie

OWASP deelt NoSQL-injectie in onder de categorie Injection in zowel de Top 10 van 2021 als de Top 10 van 2025. De kwetsbaarheid behoort tot dezelfde risicocategorie als SQL-injectie, maar heeft een andere classificatie van de hoofdoorzaak. Dat bepaalt hoe u erop test en erover rapporteert.

Het belangrijkste verschil zit in de CWE-toewijzing. Traditionele SQL-injectie valt onder CWE-89 (Onjuiste neutralisatie van speciale elementen die in een SQL-opdracht worden gebruikt), terwijl NoSQL-injectie onder CWE-943 (Onjuiste neutralisatie van speciale elementen in databasequerylogica) valt. CWE-943 omvat ook andere querytalen dan SQL, waaronder MongoDB-operators voor Binary JSON (BSON), Redis-protocolopdrachten en REST-gebaseerde query's van CouchDB.

Als uw programma voor beveiligingstests of compliancerapportage alleen CWE-89 bijhoudt, kunnen bevindingen over NoSQL-injectie verkeerd worden ingedeeld of volledig worden gemist. Stem uw tools en classificatie af op CWE-943 om deze blinde vlek weg te nemen. 

Nu de classificatie duidelijk is, bekijken we de specifieke technieken waarmee aanvallers NoSQL-queryinterfaces misbruiken.

Hoe werkt NoSQL-injectie?

NoSQL-injectie misbruikt het verschil tussen wat uw applicatie verwacht van gebruikersinvoer en wat zij daadwerkelijk ontvangt. Waar SQL-injectie zich richt op een universele querytaal, verschilt NoSQL-injectie per database. MongoDB gebruikt BSON/JSON-queryoperators, Redis gebruikt het Redis Serialization Protocol (RESP) als communicatieprotocol en CouchDB biedt een HTTP REST API. Elke database kent een andere aanvalsoppervlak, maar het kernprincipe blijft hetzelfde: door de gebruiker aangeleverde gegevens komen zonder goede validatie in een query terecht en veranderen de logica ervan.

Operatorinjectie: het meest voorkomende patroon

In een typische Node.js-applicatie met MongoDB als database kan een login-endpoint een query als deze opbouwen:

Een legitiem verzoek verstuurt {"username":"admin","password":"secret"}. Maar een aanvaller kan het volgende indienen:

De operator $ne (niet gelijk aan) geeft MongoDB de opdracht alle gebruikers terug te geven van wie de gebruikersnaam en het wachtwoord niet gelijk zijn aan "invalid". Daardoor voldoen alle geldige accounts aan de query. Met één verzoek wordt de authenticatie omzeild, zonder brute force.

JavaScript-injectie via $where

Wanneer applicaties gebruikersinvoer doorgeven aan de MongoDB-operator $where of aan functies zoals mapReduce, $accumulator of $function, voert de database die invoer uit als JavaScript op de server. Een aanvaller die een payload met een eindeloze lus injecteert, kan de MongoDB-instantie blokkeren en een denial-of-service veroorzaken. Naast toegang tot gegevens kan de uitvoering van willekeurige JavaScript-code leiden tot uitvoering van code op afstand op de databaseserver.

Blinde gegevensextractie

Wanneer de applicatie queryresultaten niet rechtstreeks teruggeeft, gebruiken aanvallers booleaanse of op timing gebaseerde technieken om gegevens teken voor teken te achterhalen. Door regex-patronen in te dienen, zoals password[$regex]=^a, en te controleren of het antwoord afwijkt van een conditie waarvan bekend is dat die onwaar is, kan een aanvaller wachtwoorden, tokens en andere geheimen reconstrueren zonder ooit een direct datalek te zien.

Redis-commando-injectie via CRLF

In RESP worden commando's gescheiden door reeksen van carriage return en line feed (CRLF) (\r\n). Wanneer een applicatie gebruikersinvoer zonder opschoning toevoegt aan commando's op Redis-protocolniveau, kan een aanvaller CRLF-reeksen injecteren om het huidige commando te beëindigen en ongeautoriseerde commando's via dezelfde verbinding mee te sturen.

Redis slaat gegevens op als sleutel-waardeparen. Geïnjecteerde commando's zoals SET, GET en CONFIG kunnen gevoelige gegevens lezen, sleutels overschrijven of de server volledig herconfigureren. Deze techniek wordt vaak gecombineerd met Server-Side Request Forgery (SSRF). Daarbij gebruikt de aanvaller een SSRF-kwetsbaarheid om een interne Redis-instantie te bereiken die niet toegankelijk is via het openbare internet. Vervolgens injecteert de aanvaller via het SSRF-kanaal extra commando's.

HTTP API-injectie in CouchDB

CouchDB biedt een REST/HTTP API, waardoor alle databasebewerkingen verlopen via standaard HTTP-verzoeken met JSON-payloads. Injectie ontstaat wanneer een applicatie niet-opgeschoonde gebruikersinvoer doorgeeft aan CouchDB-queryparameters, viewdefinities of Mango-selectorobjecten.

Omdat CouchDB MapReduce-views gebruikt die in JavaScript zijn geschreven, bestaat er een risico op code-uitvoering op de server, vergelijkbaar met dat van de MongoDB-operator $where. Een aanvaller die de JavaScript-code in een MapReduce-view kan beïnvloeden, kan willekeurige code op de databaseserver uitvoeren. Ook de replicatiefunctie van CouchDB kan via speciaal vervaardigde HTTP-verzoeken worden misbruikt om SSRF tegen interne diensten uit te voeren.

Elke NoSQL-database heeft een eigen aanvalsoppervlak, of het nu gaat om de BSON-operatoren van MongoDB, CRLF-injectie op Redis-protocolniveau of de REST-gebaseerde API van CouchDB. Uw verdediging tegen NoSQL-injectie moet aansluiten op de specifieke query-interface van elke database.

Deze mechanismen werken bij verschillende contenttypen, transportlagen en frameworks. De onderliggende oorzaken keren steeds terug. Juist daarin ligt het voordeel voor verdedigers.

Oorzaken van NoSQL-injectie

NoSQL-injectie ontstaat niet door één programmeerfout. Het is het resultaat van architectuuraannames, frameworkgedrag en ontbrekende validatielagen die elkaar tijdens de uitvoering versterken.

Onvoldoende invoervalidatie en ontbrekende typecontrole

Uw applicatie gaat er mogelijk van uit dat een veld zoals password altijd als string binnenkomt, maar HTTP-requestbody's, JSON-payloads en URL-gecodeerde parameters kunnen ook objecten en arrays bevatten. Wanneer de body-parser van Express.js password[$ne]=x ontvangt, deserialiseert deze de waarde automatisch naar { password: { $ne: "x" } }, een MongoDB-operatorobject, nog voordat de applicatiecode ermee in aanraking komt.

Dynamische opbouw van query's

Als u query's opbouwt door strings samen te voegen of te interpoleren in plaats van gestructureerde queryobjecten te gebruiken, kunnen aanvallers de querysyntaxis doorbreken en nieuwe logica injecteren. Het MongoDB-forum bevestigt: "In de meeste gevallen ontstaan externe injecties doordat strings onveilig worden samengevoegd bij het opbouwen van query's."

JavaScript aan de serverzijde ingeschakeld laten

MongoDB ondersteunt de uitvoering van JavaScript via $where, mapReduce, $accumulator en $function. De MongoDB-checklist adviseert expliciet om scripts aan de serverzijde uit te schakelen met --noscripting wanneer deze bewerkingen niet worden gebruikt. Als ze ingeschakeld blijven, ontstaat een aanvalsoppervlak voor de uitvoering van willekeurige code.

Typeconversie op frameworkniveau

PHP zet username[$ne]=toto automatisch om naar ['username' => ['$ne' => 'toto']]. De body-parser van Express.js doet hetzelfde met URL-gecodeerde formuliergegevens en deserialiseert password[$ne]=x naar { password: { $ne: "x" } }, een MongoDB-operatorobject, nog voordat het verzoek de applicatiecode bereikt. Door dit frameworkgedrag veranderen onschuldig ogende HTTP-parameters in databaseoperators zonder dat de ontwikkelaar daar bewust iets voor doet.

Kwetsbaarheden in de ORM-laag

Zelfs als MongoDB zelf is beveiligd, kan de object-relationele mappingbibliotheek (ORM) van uw applicatie mogelijkheden voor injectie introduceren. CVE-2024-53900 liet zien dat de operator $where van Mongoose via door gebruikers beheerde invoer kon worden misbruikt, en CVE-2025-23061, een onvolledige oplossing voor de eerste kwetsbaarheid, liet zien dat $where nog steeds kon worden omzeild door deze onder $or in de populate().match-functie van Mongoose, waardoor beveiligingen op serverniveau volledig worden omzeild.

Uitgeschakelde validatie van het wire protocol

MongoDB valideert binnenkomende documenten op wire-protocolniveau via de instelling net.wireObjectCheck. Als deze is uitgeschakeld, verdwijnt een structurele beveiligingslaag die voorkomt dat onjuist gevormde BSON de query-engine bereikt.

Deze oorzaken creëren een aanvalsoppervlak dat zich uitstrekt van HTTP-parsing tot database-uitvoering en rechtstreeks leidt tot bedrijfsrisico's.

Impact en risico

NoSQL-injectie raakt alle aspecten van vertrouwelijkheid, integriteit en beschikbaarheid binnen de (CIA)-triade, vaak tegelijkertijd.

• Vertrouwelijkheid: Aanvallers kunnen willekeurige documenten lezen, veldnamen inventariseren en met blinde injectietechnieken inloggegevens teken voor teken buitmaken. Bij CVE-2021-22911 wisten onderzoekers hashes van beheerderswachtwoorden en tokens voor het opnieuw instellen van wachtwoorden uit Rocket.Chat-instanties te halen.
• Integriteit: Via operatorinjectie en misbruik van onbewerkte query's kunnen aanvallers documenten wijzigen, vervangen of verwijderen. Meegesmokkelde query's kunnen volledig nieuwe records invoegen of bestaande veldwaarden overschrijven.
• Beschikbaarheid: Een $where-payload met een eindeloze lus kan een MongoDB-instantie volledig bezighouden en de database effectief onbereikbaar maken, zonder het netwerk met verkeer te overspoelen.
• Het omzeilen van authenticatie is een van de meest gedocumenteerde gevolgen. Daarmee vormt NoSQL-injectie een directe weg naar initiële toegang tot publiek toegankelijke applicaties.
• Risico's voor de toeleveringsketen en downstreamgebruikers vergroten de reikwijdte van NoSQL-injectie in platformproducten. Als een kwetsbaarheid een platform zoals Rocket. Chat of Parse Server compromitteert, worden ook tenants en downstreamgebruikers van dat platform getroffen. Eén injectiefout in een backend-as-a-service-product kan vele applicaties blootstellen die op dat platform zijn gebouwd. Zo leidt één kwetsbaarheid tot inbreuken in vele omgevingen.
• Regelgeving en compliance brengen directe gevolgen met zich mee bij schendingen van de vertrouwelijkheid. Als NoSQL-injectie het buitmaken van persoonsgegevens, inloggegevens of klantcommunicatie mogelijk maakt, moeten organisaties voldoen aan meldplichten onder kaders zoals GDPR, HIPAA, PCI DSS en privacywetgeving op staatsniveau. De techniek waarbij bij blinde injectieaanvallen gegevens teken voor teken worden buitgemaakt, kan gedurende lange tijd ongemerkt gevoelige data wegsluizen. Die gestage stroom is gemakkelijk te missen. Vroege detectie is daarom essentieel.

• Uitvoering van code op afstand is bevestigd via JavaScript-evaluatie aan de serverzijde. De OWASP WSTG stelt dat "omdat JavaScript een volwaardige programmeertaal is, een aanvaller niet alleen gegevens kan manipuleren, maar ook willekeurige code kan uitvoeren." Een paper van het International Symposium on Digital Forensics and Security (ISDFS) uit 2025 beschrijft dit risico onomwonden: "Omdat JavaScript krachtig is, is het blootstellen van zo'n kwetsbaarheid te vergelijken met het geven van een machinegeweer aan een topcrimineel."

Wie de werkwijze van aanvallers kent, kan elke fase ervan doorbreken. Zo verloopt die werkwijze.

Hoe aanvallers NoSQL-injectie misbruiken

Aanvallers volgen een gestructureerde methode om NoSQL-injectie te vinden en te misbruiken, van verkenning tot data-exfiltratie of code-uitvoering.

Fase 1: invoerpunten vinden

De aanvaller identificeert parameters die aan een NoSQL-backend worden doorgegeven: URL-parameters, JSON POST-bodies, HTTP-headers en WebSocket-berichten. Vervolgens dient de aanvaller testtekens in (' " \ ; { }) en let op foutmeldingen of gedragsveranderingen die interactie met de database onthullen.

Fase 2: operatorinjectie bevestigen

Bij een inlogendpoint vervangt de aanvaller een normale aanmeldgegevensreeks door een $ne-operator:

Als de applicatie een succesvolle aanmelding voor een andere gebruiker teruggeeft, is operatorinjectie bevestigd. De aanvaller kan ook de $gt (groter dan)-operator testen als alternatieve bevestiging:

De $gt -operator met een lege tekenreeks komt overeen met elke niet-lege wachtwoordwaarde. Als de aanmelding bij het beheerdersaccount slaagt zonder geldig wachtwoord, is operatorinjectie opnieuw bevestigd.

Fase 3: authenticatie omzeilen

De aanvaller gaat een stap verder door in beide velden operatoren te injecteren:

Dit richt zich specifiek op accounts met verhoogde rechten en geeft de eerste gebruiker terug wiens gebruikersnaam overeenkomt met de lijst en wiens wachtwoord een niet-lege tekenreeks is.

Fase 4: data-exfiltratie

Met $where-JavaScript-injectie onderzoekt de aanvaller of een veld bestaat:

Als de respons overeenkomt met een bekend geldig patroon, bestaat het veld resetToken. De aanvaller haalt de waarde vervolgens teken voor teken op via blinde injectie op basis van waar/onwaar-uitkomsten. Daarbij dient de aanvaller een regex-patroon in zoals {"resetToken":{"$regex":"^A"}} en observeert de HTTP-respons. Een successtatuscode of een specifieke responsinhoud geeft aan dat het teken overeenkomt. Een andere respons geeft aan dat het niet overeenkomt. De aanvaller doorloopt elke tekenpositie en test bij elke stap alle mogelijke tekens. Zoals beschreven in CVE-2024-37405, kan deze extractie via herhaalde verzoeken en vergelijking van de responsen plaatsvinden. Daarmee is blinde injectie een praktische aanval, niet slechts een theoretisch risico.

Fase 5: rechten verhogen en lateraal bewegen

Met buitgemaakte aanmeldgegevens of resettokens krijgt de aanvaller beheerderstoegang. Vervolgens kan de aanvaller toegang krijgen tot backendsystemen, andere collecties benaderen via injectie in de aggregatiepipeline met $lookup of $unionWith (door PortSwigger genomineerd als een van de belangrijkste webhackingtechnieken), of blijvende toegang verkrijgen via code-uitvoering aan de serverzijde. Injectie in de aggregatiepipeline met $lookup heeft grote gevolgen: hiermee kunnen collecties worden uitgelezen waartoe de applicatiequery nooit toegang had mogen hebben. Zo worden toegangsgrenzen tussen collecties doorbroken en kunnen gegevens uit de hele database worden blootgesteld.

Wisselen van Content-Type

Aanvallers wisselen vaak tussen application/x-www-form-urlencoded en application/json om injectiepunten te vinden die slechts bij één contenttype bestaan. Deze techniek is vooral effectief tegen REST APIs die meerdere formaten verwerken.

Deze aanvalstechnieken zijn toepasbaar overal waar NoSQL-databases gebruikersinvoer accepteren. Sommige applicaties staan veel directer bloot aan aanvallen dan andere.

Wie loopt risico?

NoSQL-injectie treft elke applicatie die door gebruikers aangeleverde invoer zonder goede typecontrole doorgeeft aan een NoSQL-database. Op basis van bevestigde CVE-gegevens lopen de volgende applicatiecategorieën het meeste risico:

• Authenticatiesystemen: Inlogendpoints vormen het typische aanvalsoppervlak dat in alle belangrijke bronnen wordt beschreven.
• Platforms voor teamsamenwerking: Voor Rocket.Chat zijn over meerdere jaren diverse CVEs voor NoSQL-injectie geregistreerd, waaronder een kwetsbaarheid die zonder authenticatie kan worden misbruikt (CVE-2021-22911).
• Node.js/Express-applicaties die Mongoose gebruiken: Mongoose, een object document mapper (ODM), introduceert mogelijkheden voor injectie op de ORM-laag, onafhankelijk van de beveiligingsmaatregelen van MongoDB zelf.
• Platform-as-a-service-backends: Parse Server (CVE-2022-24815, CVE-2026-30941) en Steedos Platform (CVE-2020-35666) laten zien dat backend-as-a-service-producten kwetsbaar kunnen zijn.
• IoT en netwerkbeheer: De leverancier bevestigde een CVE voor NoSQL-injectie in de UniFi Network Application van Ubiquiti, waarmee privileges konden worden verhoogd.
• E-commerceplatforms: AquilaCMS kreeg een beoordeling als KRITIEK voor NoSQL-injectie in de functie voor het opnieuw instellen van wachtwoorden (CVE-2024-48573).
• GraphQL-API's: GraphQL-filterargumenten die zonder opschoning rechtstreeks in MongoDB-query's terechtkomen, creëren een vaak over het hoofd geziene mogelijkheid voor injectie.

MongoDB wordt veel gebruikt en Node.js/Express is ook breed geaccepteerd voor backendontwikkeling. Samen creëren ze een groot aanvalsoppervlak. NIST IR 8504 documenteert NoSQL-injectie formeel als een erkende risicocategorie voor systemen van de Amerikaanse overheid. Dat onderstreept dat dit risico ook voor grote organisaties geldt, niet alleen voor startups of SaaS-omgevingen.

GraphQL-API's vormen een steeds vaker voorkomende aanvalsvector, omdat filterargumenten vaak zonder expliciete lijst met toegestane waarden rechtstreeks in MongoDB-query's terechtkomen. Traditionele traditionele regels voor webapplicatiefirewalls (WAF) die zich richten op SQL-achtige payloads, dekken dit patroon nauwelijks.

De gemene deler is niet de sector, maar de technologiestack. Gebruikt u MongoDB, Redis, CouchDB of Elasticsearch met invoer van gebruikers, dan is uw applicatie een potentieel doelwit. Dat geldt vooral als u bouwt op JavaScript-frameworks die automatisch typen converteren. De volgende bevestigde incidenten laten zien hoe misbruik er in de praktijk uitziet.

Voorbeelden uit de praktijk

Bevestigde CVE's en gepubliceerde aanvalsketens laten zien hoe NoSQL-injectie uitpakt in productieomgevingen, van samenwerkingsplatforms en e-commerce tot backend-as-a-service-producten en netwerkinfrastructuur.

Rocket.Chat: overname van een beheerdersaccount zonder voorafgaande authenticatie (CVE-2021-22911)

Onderzoek van SonarSource toonde aan dat de methode getPasswordPolicy() van Rocket.Chat zonder authenticatie kon worden aangeroepen. Door de MongoDB-operator $regex in de parameter voor het token voor wachtwoordherstel te injecteren, kon een aanvaller het token teken voor teken achterhalen. Daarvoor verstuurde de aanvaller {"$regex":"^A"} en observeerde verschillen in de reacties.

Het bevestigde HackerOne-rapport beschreef de aanvalsketen: het buitmaken van gebruikersnamen van beheerders, e-mailadressen, wachtwoordhashes en hersteltokens, met als eindresultaat de volledige overname van een beheerdersaccount.

@feathersjs/mongodb: objectinjectie via WebSocket (CVE-2026-29793)

Socket.IO-clients konden willekeurige JavaScript-objecten als de id parameter naar elke methode van een Feathers-service sturen. De transportlaag controleerde het type niet. Door {$ne: null} als de id waarde te versturen, werd elk document in een collectie gevonden. De kwetsbaarheid is geregistreerd als CVE-2026-29793.

Ubiquiti UniFi: privilege-escalatie na authenticatie (CVE-2026-22557)

Ubiquiti bevestigde in een eigen beveiligingsadvies een NoSQL-injectiekwetsbaarheid in de UniFi Network Application die na authenticatie privilege-escalatie mogelijk maakte. Elke geauthenticeerde gebruiker kon de kwetsbaarheid misbruiken om hogere toegangsrechten te krijgen en zo vanuit een account met beperkte rechten volledige beheerderscontrole over de netwerkinfrastructuur te verkrijgen.

Rocket.Chat Livechat: gekoppelde injectie (CVE-2024-37405)

Twee afzonderlijke NoSQL-injectiepunten werden aan elkaar gekoppeld: het extraheren van een bezoekerstoken via $regex met blinde injectie, gevolgd door een tweede injectie in de rid-parameter om alle Livechat-berichten uit te lezen. Deze aanval zonder voorafgaande authenticatie legde klantcommunicatie bloot.

AquilaCMS: kritieke injectie in de functie voor het opnieuw instellen van wachtwoorden (CVE-2024-48573)

AquilaCMS, een opensource-e-commerceplatform, kreeg een beoordeling KRITIEK (9.8) voor een NoSQL-injectiekwetsbaarheid in de functie voor het opnieuw instellen van wachtwoorden. Een aanvaller zonder authenticatie kon het proces voor het opnieuw instellen van wachtwoorden manipuleren door MongoDB-operators in de resettokenparameter te injecteren en zo de beoogde validatielogica volledig te omzeilen. Omdat AquilaCMS webwinkels aandrijft, bracht succesvolle uitbuiting klantaccountgegevens, betaalgegevens en bestelgeschiedenissen in gevaar. Voor deze kwetsbaarheid was geen authenticatie vereist en deze kon op afstand worden uitgebuit via een standaard HTTP-verzoek, waardoor elke aanvaller met netwerktoegang tot de webwinkel haar kon uitbuiten.

Parse Server: terugkerende injectiekwetsbaarheden (CVE-2022-24815, CVE-2026-30941)

Parse Server, een veelgebruikt open-source backend-as-a-service-platform, heeft door de jaren heen herhaaldelijk NoSQL-injectiekwetsbaarheden gehad. CVE-2022-24815 combineerde prototype pollution met NoSQL-injectie. Dit toont aan hoe kwetsbaarheden in de JavaScript-laag en database-injectie samen aanvalspaden creëren die geen van beide kwetsbaarheden afzonderlijk mogelijk zou maken. Jaren later liet CVE-2026-30941 zien dat het platform nog steeds injectiepunten had waar tokenwaarden zonder typevalidatie aan databasequery's werden doorgegeven. Backend-as-a-service-producten zijn aantrekkelijke doelwitten omdat één kwetsbaarheid gevolgen heeft voor elke applicatie die op het platform is gebouwd. Als Parse Server wordt gecompromitteerd, kunnen mobiele apps, webapplicaties en IoT-backends die ervan afhankelijk zijn aan hetzelfde risico worden blootgesteld.

Deze incidenten beslaan meerdere jaren en technologiestacks. NoSQL-injectie duikt steeds weer op in productiesystemen. De tijdlijn laat zien hoe lang dit patroon al speelt.

Tijdlijn van NoSQL-injectie

De reeks CVE's uit 2026 wijst op toenemende aandacht van onderzoekers voor Node.js/MongoDB-stacks. NoSQL-injectie lijkt opnieuw aandacht te trekken in plaats van uit beeld te verdwijnen. Daarom heeft detectie prioriteit. Het goede nieuws: de signalen zijn goed bekend.

NoSQL-injectie detecteren

Voor het opsporen van NoSQL-injectie zijn statische codeanalyse, dynamische tests op actieve endpoints en gedragsmonitoring tijdens runtime nodig. Zo ontdekt u ook aanvallen die uw andere beveiligingsmaatregelen missen.

Statische analyse en codereview

Controleer uw codebase op risicovolle patronen. Markeer elke Mongoose .find(), .findOne(), of .populate()-aanroep die rechtstreeks req.body, req.query, of req.params doorgeeft zonder typecontrole. Zoek naar elk gebruik van $where met invoer die gebruikers kunnen beïnvloeden, aggregatiepijplijnen met filterobjecten die gebruikers kunnen beïnvloeden en endpoints die ruwe JSON-queryobjecten van clients accepteren. Markeer daarnaast elk gebruik van eval(), Function(), of template literals die gebruikersinvoer samenvoegen tot querystrings. Onderzoek aggregatiepijplijnen met $lookup of $unionWith en collectienamen of pijplijnfasen die gebruikers kunnen beïnvloeden extra zorgvuldig, omdat deze de toegangsgrenzen tussen collecties kunnen doorbreken.

Dynamisch testen

Volg de OWASP WSTG-INPV-05.6-methodologie:

1. Dien de fuzz-string '"\{ ;$Foo} $Foo \xYZ` in om punten voor syntaxinjectie te vinden.
2. Dien de speciale tekens ' " \ ; { } in om punten voor operatorinjectie te vinden.
3. Gebruik HTTP Parameter Pollution om een $where-parameter te injecteren en de foutmeldingen van MongoDB te bekijken.
4. Vergelijk de antwoorden op voorwaarden die aantoonbaar waar of onwaar zijn om blinde injectie op te sporen.

Test ook specifiek WebSocket-kanalen. CVE-2026-29793 liet zien dat Socket.IO-clients willekeurige JavaScript-objecten als argumenten voor servicemethoden konden versturen en zo alle inspectie op HTTP-niveau omzeilden. Veel scanners richten zich uitsluitend op HTTP-endpoints en missen injectiemogelijkheden via WebSocket volledig. Handmatige of gespecialiseerde WebSocket-tests dichten dat gat voor applicaties die op frameworks voor realtimecommunicatie zijn gebouwd.

Gedragsmonitoring tijdens uitvoering

Controleer uw infrastructuur op gedragsindicatoren van geslaagde uitbuiting:

• Databaseserviceprocessen (mongod, redis-server) die onverwachte onderliggende processen of shells starten
• Ongebruikelijke querypatronen met MongoDB-operatorsyntaxis ($where, $regex, $ne, $gt) in applicatielogs
• CPU-pieken op MongoDB-servers zonder overeenkomstige legitieme querybelasting
• Wachtwoordreset endpoints die in tokenvelden objecten ontvangen in plaats van tekenreeksen
• Verschillen in responstijden van publiek toegankelijke endpoints die wijzen op blinde injectie op basis van timing

Tools voor penetratietests

Met gespecialiseerde tools kunt u tijdens beoordelingen testen op NoSQL-injectie:

• NoSQLMap: Opensourcetool die speciaal is ontwikkeld om NoSQL-injectie te testen en uit te buiten
• nosqli: Opdrachtregeltool voor het automatisch opsporen van NoSQL-injectie
• Burp Suite: Handmatig testen via de modules Repeater en Intruder, met extensies voor het automatisch testen van NoSQL-payloads
• OWASP ZAP: Actieve scanregels voor NoSQL-endpoints

Weten waar u moet zoeken is de helft van de uitdaging. De andere helft is verdediging opbouwen die misbruik vanaf het begin voorkomt.

NoSQL-injectie voorkomen

Voorkom NoSQL-injectie door strikte typecontroles af te dwingen voor alle gebruikersinvoer voordat die de databaselaag bereikt. De onderstaande maatregelen pakken elke eerder genoemde oorzaak aan, van typeconversie op frameworkniveau tot het omzeilen van de ORM-laag.

Controleer typen voordat u query's opbouwt

Wijs elk invoerveld af dat geen scalaire waarde is (tekenreeks, getal, booleaanse waarde) voordat het uw ORM of databasedriver bereikt. Expliciete typeconversie is de effectiefste verdediging:

Verwijder of wijs MongoDB-operatorsleutels af

Controleer alle sleutels in req.body, req.query, en req.params op $ als voorvoegsel en wijs ze af voordat ze de databaselaag bereiken. Gebruik key.startsWith('$') als controle in plaats van regex, waarvoor omzeilingen zijn gedocumenteerd in CVE-2021-22910.

Schakel JavaScript op de server uit

Gebruik --noscripting of stel security.javascriptEnabled: false in uw MongoDB-configuratie in. Daarmee verdwijnt de aanvalsoppervlakte van $where volledig. Gebruik bij voorkeur $expr en getypeerde querybouwers voor voorwaardelijke logica.

Gebruik frameworks voor schemavalidatie

Valideer gegevenstypen vroeg in de verwerking van verzoeken met bibliotheken zoals Joi, Ajv of Zod. Deze weigeren arrays of objecten waar scalaire waarden worden verwacht. Zo stopt u operatorinjectie voordat die de database bereikt.

Leg versies van Mongoose en ORM vast en volg beveiligingsadviezen

Kwetsbaarheden in de ORM-laag kunnen controles op applicatie- en databaseniveau volledig omzeilen. CVE-2024-53900 en CVE-2025-23061 toonden aan dat de Mongoose-functie populate().match kon worden misbruikt, zelfs wanneer JavaScript aan de serverzijde van MongoDB was uitgeschakeld. CVE-2025-23061 was een onvolledige oplossing voor CVE-2024-53900. Dit laat zien dat patches zelf tekort kunnen schieten en onafhankelijk moeten worden geverifieerd.

Abonneer u op beveiligingsadviezen voor Mongoose en andere ODM/ORM-bibliotheken, leg afhankelijkheidsversies expliciet vast en controleer of elke beveiligingspatch de gedocumenteerde kwetsbaarheid volledig verhelpt voordat u het bijbehorende ticket sluit.

Accepteer nooit onbewerkte JSON-query's van clients

De OWASP-cheatsheet stelt expliciet: "Accepteer geen onbewerkte JSON-query's van clients." Een payload zoals { "$where": "this.balance > 0" } die door een client wordt ingediend, leidt tot uitvoering van code op afstand of uitputting van de CPU.

Configureer de database volgens het principe van minimale rechten

Gebruik specifieke databaseaccounts voor applicaties met minimale rechten. Maak nooit verbinding met root- of beheerdersgegevens. Stel databasepoorten of beheerconsoles niet bloot aan het openbare internet.

Houd Wire Object Check ingeschakeld

De instelling net.wireObjectCheck van MongoDB valideert alle documenten op het niveau van het wire-protocol. Deze is standaard ingeschakeld. Schakel deze nooit uit.

Beveilig GraphQL-filters

Verwerk GraphQL-filterargumenten via een expliciete lijst met toegestane waarden. Neem nooit niet-vertrouwde objecten rechtstreeks op in queryfilters van MongoDB of Mongoose.

Sterke controles op applicatieniveau verkleinen het aanvalsoppervlak. Ze kunnen het niet volledig wegnemen. Gelaagde detectie en respons vangen op wat erdoorheen glipt.

Tools voor detectie en preventie

Gelaagde verdediging tegen NoSQL-injectie combineert controles op applicatieniveau, testtools en runtimebewaking.

• Verdediging op applicatieniveau omvat bibliotheken voor invoervalidatie (Joi, Ajv, Zod), beveiligingsmaatregelen op ORM-niveau (schemavalidatie in Mongoose, expliciete typeconversie) en de ingebouwde beveiligingsmaatregelen van MongoDB (--noscripting, wireObjectCheck, rolgebaseerde toegang).
• Testtools zoals NoSQLMap, nosqli, Burp Suite en OWASP ZAP onderzoeken applicaties op NoSQL-injectie tijdens ontwikkeling en penetratietests.
• WAFs vormen een extra verdedigingslaag aan de rand van het netwerk die bekende injectiepatronen kan blokkeren. Maar WAFs werken met regels op basis van signatures en kunnen nieuwe payloads, verhulde operators of injectie via WebSocket-kanalen niet stoppen.
• Runtimebewaking van gedrag vult de lacune die WAFs openlaten. Controles op applicatieniveau kunnen worden omzeild met nieuwe payloads, kwetsbaarheden in de ORM-laag zoals het probleem met populate().match in Mongoose, of WebSocket-kanalen die WAFs niet inspecteren. Runtimebewaking signaleert de gevolgen van geslaagde injectie, zoals databaseprocessen die onverwachte shells starten, afwijkende patronen in de uitvoering van JavaScript of ongebruikelijke aantallen query's, ongeacht hoe de payload is afgeleverd. Wanneer een injectiepayload inspectie op basis van signatures ontwijkt en de database bereikt, vormt het resulterende afwijkende gedrag de betrouwbaarste indicator van een inbreuk.

Hoe ondersteunt SentinelOne?

Payloadinspectie is de taak van de WAF. SentinelOne bewaakt wat daarna gebeurt. Het detecteert en stopt de gevolgen van geslaagde NoSQL-injectie: procesafwijkingen, laterale beweging en activiteiten na de exploitatie die controles op applicatieniveau missen.

SentinelOne's Singularity™ Platform omvat Singularity AI SIEM, die telemetrie van endpoints, cloudworkloads, identiteitssystemen en externe bronnen in één data lake correleert. Tijdens de MITRE ATT&CK Evaluations van 2024 behaalde het Singularity Platform 100% detectie zonder vertragingen en genereerde het 88% minder meldingen dan de mediaan. Minder ruis betekent dat uw team zich kan richten op bevestigde dreigingen. Wanneer een NoSQL-injectieaanval van een webapplicatie via een databaseserver tot diefstal van inloggegevens leidt, koppelt AI SIEM die gebeurtenissen zonder handmatige correlatie.

Binnen Singularity Endpoint brengt Storyline op elk beschermd endpoint voortdurend gebeurtenissen rond het starten van processen, netwerkverbindingen, bestandswijzigingen en het gebruik van inloggegevens samen in samenhangende ketens die de herkomst inzichtelijk maken. Bij een op $where gebaseerde aanval waarbij JavaScript aan de serverzijde wordt uitgevoerd, koppelt Storyline autonoom het webserverproces dat het kwaadaardige verzoek ontvangt, de databaseservice die afwijkend gedrag vertoont, het gestarte interpreterproces en eventuele onderliggende shells aan één Storyline ID. Aangepaste regels van Storyline Active Response (STAR) worden geactiveerd wanneer databaseprocessen zoals mongod of redis-server onverwachte onderliggende processen starten. Dat is een betrouwbare gedragsindicator voor geslaagde command injection.

Purple AI™ versnelt onderzoeken met zoekopdrachten in natuurlijke taal. Volgens IDC identificeren klanten van Purple AI bedreigingen 63% sneller en verkorten ze de gemiddelde hersteltijd (MTTR) met 55%. U kunt vragen "toon me alle processen die mongod in de afgelopen 24 uur heeft gestart" of rechtstreeks verwijzen naar MITRE ATT&CK-technieken zoals T1190 (Exploit Public-Facing Application) en T1059 (Command and Scripting Interpreter). De Auto Investigation-functionaliteit van Purple AI verzamelt autonoom bewijsmateriaal uit de hele technologiestack, brengt dreigingsgegevens samen en stelt volledige aanvalstijdlijnen op. Zo duren onderzoeken die voorheen uren kostten nog maar minuten.

Cloud Workload Security beschermt NoSQL-databases in de cloud tijdens runtime. Het bewaakt workloadgedrag in realtime en gebruikt Verified Exploit Paths om bevindingen met bewijs te onderbouwen. U ziet wanneer een NoSQL-injectie tegen een MongoDB- of Redis-instantie in de cloud leidt tot activiteiten na de exploitatie.

Voor organisaties die op grote schaal NoSQL-databases gebruiken, dichten deze mogelijkheden de kloof tussen preventie op applicatieniveau en inzicht in activiteiten na de exploitatie. 

Vraag een demo van SentinelOne aan om deze mogelijkheden in actie te zien.

Gerelateerde kwetsbaarheden

NoSQL-injectie heeft dezelfde onderliggende oorzaken en aanvalspatronen als verschillende verwante typen kwetsbaarheden:

• SQL-injectie (CWE-89): De tegenhanger bij relationele databases. Beide maken misbruik van onvoldoende neutralisatie van gebruikersinvoer in databasequery's, maar doordat NoSQL-injectie procedurele code kan uitvoeren, reikt de impact verder dan gegevensmanipulatie: ook willekeurige code kan worden uitgevoerd.
• Server-Side Request Forgery (SSRF): Redis CRLF-injectie wordt vaak gecombineerd met SSRF. Een aanvaller gebruikt SSRF om een interne Redis-instantie te bereiken en injecteert vervolgens extra opdrachten via CRLF-sequenties.
• Command Injection (CWE-78): Wanneer NoSQL-injectie via $where leidt tot uitvoering van JavaScript aan de serverzijde, lijkt de resulterende mogelijkheid sterk op OS-command injection.
• Prototype Pollution: CVE-2022-24815 in Parse Server combineerde prototype pollution met NoSQL-injectie. Dit laat zien hoe kwetsbaarheden in de JavaScript-laag de impact van database-injectie vergroten.
• Cross-Site Scripting (XSS): Zowel XSS als NoSQL-injectie komt voort uit onvoldoende validatie van invoer. Organisaties die kwetsbaar zijn voor het ene, hebben vaak structurele tekortkomingen in de validatie waardoor ze ook kwetsbaar zijn voor het andere.

Inzicht in deze verbanden helpt u tests en herstelmaatregelen voor verwante typen kwetsbaarheden te prioriteren, in plaats van elk type afzonderlijk te behandelen. De volgende tabel bevat ter referentie bevestigde CVE's voor NoSQL-injectie.