Che cos'è l'iniezione NoSQL? Come funziona e come prevenirla

Che cos'è l'iniezione NoSQL?

L'iniezione NoSQL è una vulnerabilità che permette agli attaccanti di manipolare le query inviate ai database NoSQL inserendo operatori dannosi, codice JavaScript o sintassi appositamente costruita tramite input utente non sanificati. Formalmente classificata nella Common Weakness Enumeration (CWE) come CWE-943, "Neutralizzazione impropria di elementi speciali nella logica delle query sui dati", colpisce database come MongoDB, Redis, Cassandra ed Elasticsearch, che usano linguaggi di query flessibili e privi di schema anziché SQL standard.

Un attacco riuscito ha conseguenze che vanno ben oltre una singola query alterata. Un attaccante può aggirare completamente l'autenticazione, estrarre dati sensibili carattere per carattere, modificare record, provocare condizioni di denial of service o eseguire codice arbitrario sul server. Come rileva la OWASP WSTG, "i potenziali impatti sono maggiori rispetto alla tradizionale iniezione SQL", perché i payload di iniezione NoSQL possono essere eseguiti in un linguaggio procedurale come JavaScript, non solo in un linguaggio di query dichiarativo.

Oggi i database NoSQL sono alla base di tutto, dai sistemi di accesso e le piattaforme di chat ai cataloghi e-commerce e alle console di gestione IoT. La loro crescente diffusione, unita alla convinzione errata che "niente SQL significhi niente injection", rende questa classe di vulnerabilità un rischio persistente. È un mito infondato, e gli attaccanti ci contano. 

Prima di esaminare come funziona l'iniezione NoSQL nella pratica, è utile capire dove si colloca nei framework standard di classificazione delle vulnerabilità.

Classificazione OWASP

OWASP classifica l'iniezione NoSQL nella categoria Injection sia nella Top 10 del 2021 sia nella Top 10 del 2025. Appartiene alla stessa famiglia di rischi dell'iniezione SQL, ma ha una diversa classificazione della causa principale, che incide su come la testate e la segnalate.

La distinzione fondamentale è la mappatura CWE. La tradizionale iniezione SQL rientra in CWE-89 (Neutralizzazione impropria di elementi speciali usati in un comando SQL), mentre l'iniezione NoSQL corrisponde a CWE-943 (Neutralizzazione impropria di elementi speciali nella logica delle query sui dati). CWE-943 comprende linguaggi di query diversi da SQL, inclusi gli operatori Binary JSON (BSON) di MongoDB, i comandi del protocollo Redis e le query basate su REST di CouchDB.

Se il vostro programma di test di sicurezza o la reportistica di conformità tiene traccia solo di CWE-89, i casi di iniezione NoSQL potrebbero essere classificati in modo errato o sfuggire del tutto. Allineate strumenti e tassonomia a CWE-943 per eliminare questo punto cieco. 

Definita la classificazione, il passo successivo è capire i meccanismi specifici usati dagli attaccanti per sfruttare le interfacce di query NoSQL.

Come funziona l'iniezione NoSQL?

L'iniezione NoSQL sfrutta la differenza tra ciò che la vostra applicazione si aspetta dall'input utente e ciò che riceve effettivamente. Mentre l'iniezione SQL prende di mira un linguaggio di query universale, l'iniezione NoSQL varia in base al database. MongoDB usa operatori di query BSON/JSON, Redis usa il protocollo di comunicazione Redis Serialization Protocol (RESP) e CouchDB espone un'API HTTP REST. Ogni database presenta una diversa superficie di attacco, ma il principio di base resta lo stesso: i dati controllati dall'utente entrano in una query senza un'adeguata validazione e ne modificano la logica.

Iniezione di operatori: la tecnica più comune

In una tipica applicazione Node.js basata su MongoDB, un endpoint di accesso potrebbe costruire una query come questa:

Una richiesta legittima invia {"username":"admin","password":"secret"}. Un aggressore, invece, può inviare:

L'operatore $ne (diverso da) indica a MongoDB di restituire tutti gli utenti il cui nome utente e la cui password sono diversi da "invalid", una condizione che corrisponde a ogni account valido. Basta una sola richiesta per aggirare l'autenticazione, senza ricorrere alla forza bruta.

Iniezione JavaScript tramite $where

Quando le applicazioni passano l'input dell'utente all'operatore $where di MongoDB o a funzioni come mapReduce, $accumulator o $function, il database lo esegue come JavaScript lato server. Un aggressore che inietta un payload con un ciclo continuo può bloccare l'istanza MongoDB e causare un'interruzione del servizio. Oltre all'accesso ai dati, l'esecuzione di JavaScript arbitrario può causare anche l'esecuzione di codice remoto sul server del database.

Estrazione alla cieca

Quando l'applicazione non restituisce direttamente i risultati della query, gli aggressori usano tecniche basate su condizioni booleane o sui tempi di risposta per estrarre i dati un carattere alla volta. Inviando espressioni regolari come password[$regex]=^a e osservando se la risposta differisce da quella di una condizione notoriamente falsa, un aggressore può ricostruire password, token e altri dati riservati senza mai osservare direttamente una fuga di dati.

Iniezione di comandi Redis tramite CRLF

In RESP, i comandi sono separati da sequenze di ritorno a capo e avanzamento riga (CRLF) (\r\n). Quando un'applicazione concatena l'input dell'utente ai comandi del protocollo Redis senza sanificarlo, un aggressore può iniettare sequenze CRLF per terminare il comando corrente e aggiungere comandi non autorizzati alla stessa connessione.

Redis memorizza i dati in coppie chiave-valore. Comandi iniettati come SET, GET e CONFIG possono leggere dati sensibili, sovrascrivere chiavi o riconfigurare completamente il server. Questa tecnica viene spesso combinata con la Server-Side Request Forgery (SSRF): l'aggressore sfrutta una vulnerabilità SSRF per raggiungere un'istanza Redis interna non esposta a Internet, quindi inietta comandi aggiuntivi attraverso il canale SSRF.

Iniezione nell'API HTTP di CouchDB

CouchDB espone un'API REST/HTTP: tutte le operazioni sul database avvengono tramite richieste HTTP standard con payload JSON. L'iniezione si verifica quando un'applicazione passa input dell'utente non sanificato ai parametri di query, alle definizioni delle viste o agli oggetti selettore Mango di CouchDB.

Poiché CouchDB usa viste MapReduce scritte in JavaScript, presenta un rischio di esecuzione lato server simile a quello dell'operatore $where di MongoDB. Un aggressore in grado di influenzare il JavaScript eseguito in una vista MapReduce può eseguire codice arbitrario sul server del database. Anche la funzione di replica di CouchDB può essere sfruttata tramite richieste HTTP appositamente create per attivare SSRF contro servizi interni.

Ogni database NoSQL presenta una superficie di attacco distinta: gli operatori BSON di MongoDB, l'iniezione CRLF nel protocollo Redis o l'API REST di CouchDB. Le vostre difese contro l'iniezione NoSQL devono essere adattate all'interfaccia di query specifica di ogni database.

Questi meccanismi funzionano con diversi tipi di contenuti, livelli di trasporto e framework. Le cause alla base si ripetono, ed è proprio questa ripetizione a dare un vantaggio ai team di sicurezza.

Cause della NoSQL injection

La NoSQL injection non nasce da un singolo errore di programmazione. Deriva da una combinazione di presupposti architetturali, comportamenti dei framework e livelli di validazione mancanti, i cui effetti si sommano durante l'esecuzione.

Validazione inadeguata degli input e mancato controllo dei tipi

La vostra applicazione potrebbe presumere che un campo come password arrivi sempre come stringa, ma i corpi delle richieste HTTP, i payload JSON e i parametri codificati negli URL possono contenere oggetti e array. Quando body-parser di Express.js riceve password[$ne]=x, lo deserializza automaticamente in { password: { $ne: "x" } }, un oggetto con operatore MongoDB, prima ancora che il codice dell'applicazione lo elabori.

Costruzione dinamica delle query

Quando costruite le query concatenando o interpolando stringhe anziché usare oggetti query strutturati, gli aggressori possono alterarne la sintassi e inserire nuova logica. Il forum MongoDB conferma: "Nella maggior parte dei casi, le injection esterne derivano dalla concatenazione non sicura di stringhe durante la creazione delle query."

JavaScript lato server lasciato abilitato

MongoDB supporta l'esecuzione di JavaScript tramite $where, mapReduce, $accumulator e $function. La checklist di MongoDB raccomanda esplicitamente di disabilitare lo scripting lato server con --noscripting quando queste operazioni non sono in uso. Lasciarle abilitate crea una superficie di attacco per l'esecuzione di codice arbitrario.

Conversione dei tipi a livello di framework

PHP converte automaticamente username[$ne]=toto in ['username' => ['$ne' => 'toto']]. Il body-parser di Express.js fa lo stesso con i dati dei moduli codificati negli URL, deserializzando password[$ne]=x in { password: { $ne: "x" } }, un oggetto con operatore MongoDB, prima ancora che la richiesta raggiunga il codice dell'applicazione. Questi comportamenti dei framework trasformano parametri HTTP apparentemente innocui in operatori di database senza alcun intervento intenzionale dello sviluppatore.

Vulnerabilità a livello ORM

Anche quando MongoDB è configurato in modo sicuro, la libreria di object-relational mapping (ORM) della vostra applicazione può introdurre superfici di attacco per le injection. CVE-2024-53900 ha dimostrato che l'operatore $where di Mongoose poteva essere sfruttato tramite input controllati dagli utenti, mentre CVE-2025-23061, una correzione incompleta della prima vulnerabilità, ha mostrato che le protezioni per $where potevano ancora essere aggirate inserendo l'operatore all'interno di $or nella funzionalità di Mongoose populate().match, aggirando completamente le protezioni a livello di server.

Validazione del protocollo wire disabilitata

MongoDB valida i documenti in ingresso a livello di protocollo wire tramite l'impostazione net.wireObjectCheck. Disabilitarla rimuove una protezione strutturale che impedisce ai documenti BSON malformati di raggiungere il motore di query.

Queste cause creano una superficie di attacco che va dal parsing HTTP all'esecuzione delle query nel database, traducendosi direttamente in un rischio aziendale.

Impatto e rischi

L'iniezione NoSQL colpisce riservatezza, integrità e disponibilità, le tre componenti della triade (CIA), spesso contemporaneamente.

• Riservatezza: Gli aggressori possono leggere documenti arbitrari, enumerare i nomi dei campi ed estrarre le credenziali carattere per carattere con tecniche di blind injection. Nel caso di CVE-2021-22911, i ricercatori hanno sottratto hash delle password degli amministratori e token di reimpostazione delle password da istanze di Rocket.Chat.
• Integrità: L'iniezione di operatori e l'abuso delle query non filtrate consentono agli aggressori di modificare, sostituire o eliminare documenti. Le query aggiunte a quelle legittime possono inserire record completamente nuovi o sovrascrivere i valori dei campi esistenti.
• Disponibilità: Un payload $where con un ciclo continuo può saturare un'istanza MongoDB e rendere di fatto indisponibile il database, senza richiedere un sovraccarico del traffico di rete.
• L'aggiramento dell'autenticazione è uno degli impatti più comunemente documentati. Questo rende l'iniezione NoSQL una via diretta per ottenere l'accesso iniziale alle applicazioni esposte a Internet.
• Il rischio per la supply chain e i sistemi a valle amplifica la portata dell'iniezione NoSQL nei prodotti di piattaforma. Quando una vulnerabilità compromette una piattaforma come Rocket. Chat o Parse Server, l'impatto si estende ai tenant e agli utenti a valle della piattaforma. Una singola falla di iniezione in un prodotto backend-as-a-service può esporre molte applicazioni costruite su quella piattaforma, trasformando una vulnerabilità in numerosi ambienti compromessi.
• Le conseguenze normative e di conformità derivano direttamente dalle violazioni della riservatezza. Quando l'iniezione NoSQL permette l'esfiltrazione di informazioni personali identificabili, credenziali o comunicazioni dei clienti, le organizzazioni sono soggette agli obblighi di notifica delle violazioni previsti da normative e standard come GDPR, HIPAA, PCI DSS e le leggi statali sulla privacy. La tecnica di estrazione carattere per carattere usata negli attacchi di iniezione blind può esfiltrare silenziosamente dati sensibili per lunghi periodi. Questo flusso lento è facile da non rilevare, perciò individuarlo tempestivamente è fondamentale.

• L'esecuzione di codice da remoto è confermata attraverso la valutazione di JavaScript lato server. L'OWASP WSTG afferma che "poiché JavaScript è un linguaggio completo, questo non solo consente a un aggressore di manipolare i dati, ma anche di eseguire codice arbitrario." Un articolo del Simposio internazionale sulla digital forensics e la sicurezza (ISDFS) del 2025 descrive il rischio senza mezzi termini: "Poiché JavaScript è potente, esporre una vulnerabilità del genere equivale a mettere una mitragliatrice nelle mani di un criminale esperto."

Chi difende i sistemi può interrompere ogni fase dell'attacco conoscendo le tattiche degli aggressori. Ecco come si svolge.

Come gli aggressori sfruttano l'iniezione NoSQL

Gli aggressori seguono un metodo strutturato per individuare e sfruttare l'iniezione NoSQL, passando dalla ricognizione all'esfiltrazione dei dati o all'esecuzione di codice.

Fase 1: individuazione dei vettori di input

L'aggressore individua i parametri passati a un backend NoSQL: parametri URL, corpi delle richieste JSON POST, header HTTP e messaggi WebSocket. Invia caratteri di fuzzing (' " \ ; { }) e osserva i messaggi di errore o i cambiamenti nel comportamento che rivelano l'interazione con il database.

Fase 2: conferma dell'iniezione di operatori

Su un endpoint di login, l'attaccante sostituisce una normale stringa di credenziali con un operatore $ne:

Se l'applicazione consente l'accesso come un altro utente, l'iniezione di operatori è confermata. L'attaccante può anche testare l'operatore $gt (maggiore di) per un'ulteriore conferma:

L' $gt operatore con una stringa vuota corrisponde a qualsiasi password non vuota. Se l'accesso all'account amministratore riesce senza una password valida, l'iniezione di operatori è confermata una seconda volta.

Fase 3: aggiramento dell'autenticazione

L'attaccante intensifica l'attacco iniettando operatori in entrambi i campi:

Questo prende di mira gli account privilegiati, restituendo il primo utente il cui nome utente corrisponde a uno degli elementi dell'elenco e la cui password è una qualsiasi stringa non vuota.

Fase 4: esfiltrazione dei dati

Usando $where per l'iniezione di JavaScript, l'attaccante verifica l'esistenza di un campo:

Se la risposta corrisponde a un modello noto come valido, il campo resetToken esiste. L'attaccante ne estrae quindi il valore carattere per carattere tramite blind injection basata su risposte booleane. La tecnica consiste nell'inviare un'espressione regolare come {"resetToken":{"$regex":"^A"}} e osservare la risposta HTTP. Un codice di stato di successo o un contenuto specifico della risposta indica che il carattere corrisponde, mentre una risposta diversa indica il contrario. L'attaccante procede carattere per carattere, testando ogni volta tutti i caratteri possibili. Come documentato in CVE-2024-37405, questa estrazione può avvenire tramite richieste differenziali ripetute. La blind injection è quindi un attacco praticabile, non solo un rischio teorico.

Fase 5: escalation dei privilegi e movimento laterale

Con le credenziali o i token di reimpostazione estratti, l'attaccante ottiene l'accesso amministrativo. Da lì può spostarsi verso i sistemi backend e accedere ad altre raccolte tramite l'iniezione nella pipeline di aggregazione usando $lookup o $unionWith (segnalata da PortSwigger come una delle principali tecniche di attacco alle applicazioni web), oppure stabilire una presenza persistente eseguendo codice lato server. L'iniezione nella pipeline di aggregazione con $lookup è una tecnica ad alto impatto perché può leggere raccolte a cui la query dell'applicazione non avrebbe mai dovuto accedere, superando di fatto i confini di accesso tra raccolte ed esponendo dati dell'intero database.

Cambio del Content-Type

Gli attaccanti passano spesso da application/x-www-form-urlencoded a application/json per individuare punti di iniezione presenti in un solo tipo di contenuto. La tecnica è particolarmente efficace contro le API REST che gestiscono più formati.

Queste tecniche di attacco si applicano ovunque i database NoSQL accettino input degli utenti. Alcune applicazioni sono molto più esposte di altre.

Chi è interessato?

L'iniezione NoSQL interessa qualsiasi applicazione che passa input controllato dagli utenti a un database NoSQL senza un'adeguata verifica dei tipi. In base alle vulnerabilità CVE confermate, le categorie di applicazioni più esposte includono:

• Sistemi di autenticazione: Gli endpoint di login sono la superficie di attacco più rappresentativa, documentata da tutte le principali fonti.
• Piattaforme di collaborazione tra team: Rocket.Chat è interessata da diverse vulnerabilità CVE di iniezione NoSQL documentate nel corso degli anni, tra cui una vulnerabilità sfruttabile prima dell'autenticazione (CVE-2021-22911).
• Applicazioni Node.js/Express che usano Mongoose: Mongoose, un mappatore di documenti a oggetti (ODM), introduce superfici di attacco per le injection a livello ORM, indipendentemente dai controlli di MongoDB.
• Backend platform-as-a-service: Parse Server (CVE-2022-24815, CVE-2026-30941) e Steedos Platform (CVE-2020-35666) dimostrano l'esposizione dei prodotti backend-as-a-service.
• IoT e gestione delle reti: la UniFi Network Application di Ubiquiti ha ricevuto una CVE per un'injection NoSQL confermata dal produttore che consente l'escalation dei privilegi.
• Piattaforme di e-commerce: AquilaCMS ha ricevuto una valutazione CRITICAL per un'injection NoSQL nella funzione di reimpostazione della password (CVE-2024-48573).
• API GraphQL: Gli argomenti di filtro GraphQL non sottoposti a sanitizzazione, inseriti direttamente nelle query MongoDB, creano una superficie di attacco per le injection spesso trascurata.

MongoDB è ampiamente utilizzato e Node.js/Express è altrettanto diffuso nello sviluppo di backend. Questa combinazione crea un'ampia superficie di attacco. NIST IR 8504 documenta formalmente l'injection NoSQL come categoria di rischio riconosciuta per i sistemi governativi statunitensi, sottolineando che il rischio riguarda anche le grandi aziende, non solo le startup o gli ambienti SaaS.

Le API GraphQL rappresentano un vettore sempre più comune perché gli argomenti di filtro vengono spesso inseriti direttamente nelle query MongoDB senza una allow-list esplicita, e questo schema è scarsamente coperto dalle tradizionali tradizionali regole dei web application firewall (WAF) che si concentrano sui payload in stile SQL.

Il filo conduttore non è il settore, ma lo stack tecnologico. Se usate MongoDB, Redis, CouchDB o Elasticsearch con input forniti dagli utenti, la vostra applicazione è un potenziale bersaglio, soprattutto se si basa su framework JavaScript che eseguono la conversione automatica dei tipi. I seguenti incidenti confermati mostrano come si svolge lo sfruttamento nella pratica.

Esempi reali

Le CVE confermate e le catene di exploit pubblicate mostrano come si manifesta l'injection NoSQL nei sistemi in produzione, dalle piattaforme di collaborazione all'e-commerce, fino ai prodotti backend-as-a-service e alle infrastrutture di rete.

Rocket.Chat: acquisizione di un account amministratore senza autenticazione (CVE-2021-22911)

La ricerca di SonarSource ha mostrato che il metodo getPasswordPolicy() di Rocket.Chat poteva essere chiamato senza autenticazione. Inserendo l'operatore $regex di MongoDB nel parametro del token di reimpostazione della password, un attaccante poteva estrarre il token un carattere alla volta, inviando {"$regex":"^A"} e osservando le differenze nelle risposte.

Il report confermato di HackerOne ha mostrato la catena di attacco: esposizione di nomi utente degli amministratori, indirizzi email, hash delle password e token di reimpostazione, fino alla completa acquisizione di un account amministratore.

@feathersjs/mongodb: injection di oggetti tramite WebSocket (CVE-2026-29793)

I client Socket.IO potevano inviare oggetti JavaScript arbitrari come argomento id a qualsiasi metodo del servizio Feathers. Il livello di trasporto non eseguiva alcun controllo dei tipi. Inviando {$ne: null} come argomento id si otteneva una corrispondenza con ogni documento della raccolta. La vulnerabilità è identificata come CVE-2026-29793.

Ubiquiti UniFi: escalation dei privilegi dopo l'autenticazione (CVE-2026-22557)

Un avviso di Ubiquiti ha confermato una vulnerabilità di injection NoSQL nella UniFi Network Application, sfruttabile da utenti autenticati, che consentiva l'escalation dei privilegi. Qualsiasi utente autenticato poteva sfruttare la vulnerabilità per ottenere privilegi elevati, passando da un account con privilegi limitati al pieno controllo amministrativo dell'infrastruttura di rete.

Rocket.Chat Livechat: catena di injection (CVE-2024-37405)

Due distinti punti di iniezione NoSQL sono stati concatenati: l'estrazione di un token del visitatore tramite $regex con un'iniezione cieca, seguita da una seconda iniezione nel parametro rid per estrarre tutti i messaggi Livechat. Questo attacco senza autenticazione ha esposto i dati delle comunicazioni con i clienti.

AquilaCMS: iniezione critica nella reimpostazione della password (CVE-2024-48573)

AquilaCMS, una piattaforma di e-commerce open source, ha ricevuto una valutazione CRITICA (9.8) per una vulnerabilità di iniezione NoSQL nella funzione di reimpostazione della password. Un attaccante non autenticato poteva manipolare la procedura di reimpostazione della password inserendo operatori MongoDB nel parametro del token di reimpostazione, aggirando completamente la logica di validazione prevista. Poiché AquilaCMS è alla base di negozi online, uno sfruttamento riuscito metteva a rischio i dati degli account dei clienti, le informazioni di pagamento e la cronologia degli ordini. La vulnerabilità non richiedeva autenticazione e poteva essere sfruttata da remoto tramite una normale richiesta HTTP, risultando accessibile a qualsiasi attaccante con accesso di rete al negozio online.

Parse Server: vulnerabilità di iniezione ricorrenti (CVE-2022-24815, CVE-2026-30941)

Parse Server, una piattaforma backend-as-a-service open source ampiamente utilizzata, ha presentato vulnerabilità di iniezione NoSQL ricorrenti nel corso degli anni. CVE-2022-24815 combinava la prototype pollution con l'iniezione NoSQL, dimostrando come le vulnerabilità a livello JavaScript si sommino a quelle di iniezione nel database. Insieme creano percorsi di sfruttamento che nessuna delle due falle consentirebbe da sola. Anni dopo, CVE-2026-30941 ha rivelato che la piattaforma presentava ancora punti di iniezione in cui i valori dei token venivano passati alle query del database senza validarne il tipo. I prodotti backend-as-a-service sono obiettivi di alto valore perché una singola vulnerabilità interessa ogni applicazione sviluppata sulla piattaforma. Se Parse Server viene compromesso, le app mobili, le applicazioni web e i backend IoT che vi si affidano possono essere esposti alla stessa vulnerabilità.

Questi incidenti riguardano anni e stack tecnologici diversi. L'iniezione NoSQL continua a riemergere nei sistemi di produzione e la cronologia mostra da quanto tempo persiste.

Cronologia delle iniezioni NoSQL

Il gruppo di CVE del 2026 segnala un crescente interesse dei ricercatori per gli stack Node.js/MongoDB e suggerisce che l'iniezione NoSQL stia tornando al centro dell'attenzione, anziché scomparire. Questa tendenza rende il rilevamento una priorità. La buona notizia è che i segnali sono ben noti.

Come rilevare l'iniezione NoSQL

Per individuare l'iniezione NoSQL servono analisi statica del codice, test dinamici sugli endpoint attivi e monitoraggio comportamentale in fase di esecuzione. Insieme rilevano gli attacchi che sfuggono agli altri controlli.

Analisi statica e revisione del codice

Esaminate il codice alla ricerca di pattern ad alto rischio. Segnalate ogni .find(), .findOne(), o .populate() che passa direttamente req.body, req.query, o req.params senza imporre un tipo. Cercate qualsiasi utilizzo di $where con input controllato dall'utente, qualsiasi pipeline di aggregazione che incorpori oggetti filtro controllati dall'utente e qualsiasi endpoint che accetti dai client oggetti query JSON grezzi. Segnalate inoltre qualsiasi utilizzo di eval(), Function(), o template literal che concatenino l'input dell'utente nelle stringhe di query. Esaminate con particolare attenzione le pipeline di aggregazione che usano $lookup o $unionWith con nomi di raccolte o fasi della pipeline controllati dall'utente, perché possono aggirare i confini di accesso a livello di raccolta.

Test dinamici

Seguite la OWASP WSTG-INPV-05.6 metodologia:

1. Inviate la stringa di fuzzing '"\{ ;$Foo} $Foo \xYZ` per individuare i punti di injection nella sintassi.
2. Inviate i caratteri speciali ' " \ ; { } per individuare i punti di injection degli operatori.
3. Usate HTTP Parameter Pollution per inserire un parametro $where e osservate le risposte di errore di MongoDB.
4. Confrontate le risposte a condizioni notoriamente vere e false per individuare le blind injection.

Testate anche i canali WebSocket in modo specifico. CVE-2026-29793 ha dimostrato che i client Socket.IO potevano inviare oggetti JavaScript arbitrari come argomenti dei metodi del servizio, aggirando tutti i controlli a livello HTTP. Molti scanner si concentrano esclusivamente sugli endpoint HTTP e non rilevano affatto le superfici di injection WebSocket. I test WebSocket manuali o specializzati colmano questa lacuna nelle applicazioni basate su framework di comunicazione in tempo reale.

Monitoraggio dei comportamenti in fase di esecuzione

Monitorate la vostra infrastruttura per individuare gli indicatori comportamentali di un attacco riuscito:

• Processi dei servizi di database (mongod, redis-server) che avviano processi figli o shell inattesi
• Pattern di query insoliti contenenti la sintassi degli operatori MongoDB ($where, $regex, $ne, $gt) nei log dell'applicazione
• Picchi di utilizzo della CPU sui server MongoDB senza un corrispondente carico di query legittime
• Endpoint di reimpostazione della password che ricevono oggetti anziché stringhe nei campi dei token
• Differenze nei tempi di risposta degli endpoint accessibili pubblicamente che suggeriscono un'iniezione blind basata sui tempi di risposta

Strumenti per i test di penetrazione

Usate strumenti dedicati per cercare vulnerabilità alle iniezioni NoSQL durante le valutazioni:

• NoSQLMap: Strumento open source progettato specificamente per testare e sfruttare le iniezioni NoSQL
• nosqli: Strumento a riga di comando per individuare automaticamente le iniezioni NoSQL
• Burp Suite: Test manuali tramite i moduli Repeater e Intruder, con estensioni per test automatizzati dei payload NoSQL
• OWASP ZAP: Regole di scansione attiva applicabili agli endpoint NoSQL

Sapere dove cercare è metà della sfida. L'altra metà è costruire difese che impediscano lo sfruttamento delle vulnerabilità fin dall'inizio.

Come prevenire le iniezioni NoSQL

Per bloccare le iniezioni NoSQL, applicate controlli rigorosi sui tipi di tutti gli input degli utenti prima che raggiungano il livello del database. Le difese seguenti affrontano ciascuna causa principale identificata in precedenza, dalla coercizione dei tipi a livello di framework agli aggiramenti a livello di ORM.

Verificate i tipi prima di costruire le query

Rifiutate qualsiasi campo di input che non contenga un valore scalare (stringa, numero, booleano) prima che raggiunga l'ORM o il driver del database. La coercizione esplicita dei tipi è la difesa più efficace:

Rimuovete o rifiutate le chiavi degli operatori MongoDB

Controllate tutte le chiavi in req.body, req.query e req.params per verificare la presenza di $ come prefisso e rifiutatele prima che raggiungano il livello del database. Usate key.startsWith('$') per il controllo anziché le espressioni regolari, che presentano possibilità di aggiramento note documentate in CVE-2021-22910.

Disabilitate JavaScript lato server

Usate --noscripting oppure set security.javascriptEnabled: false nella configurazione di MongoDB. Questo elimina del tutto la superficie di attacco associata a $where. Preferite $expr e i costruttori di query tipizzati per la logica condizionale.

Usate framework di validazione degli schemi

Convalidate i tipi di dati nelle prime fasi della gestione delle richieste usando librerie come Joi, Ajv o Zod. Queste rifiutano array o oggetti quando sono previsti valori scalari, bloccando l'iniezione di operatori prima che raggiunga il database.

Fissate le versioni di Mongoose e degli ORM, monitorate gli avvisi di sicurezza

Le vulnerabilità a livello ORM possono aggirare completamente i controlli applicativi e quelli del database. CVE-2024-53900 e CVE-2025-23061 hanno dimostrato che la funzionalità populate().match di Mongoose poteva essere sfruttata anche quando JavaScript lato server era disabilitato in MongoDB. CVE-2025-23061 era una correzione incompleta di CVE-2024-53900: anche le patch possono essere insufficienti e richiedono una verifica indipendente.

Iscrivetevi agli avvisi di sicurezza per Mongoose e altre librerie ODM/ORM, fissate esplicitamente le versioni delle dipendenze e verificate che ogni patch di sicurezza risolva completamente la vulnerabilità documentata prima di chiudere il ticket di correzione.

Non accettate mai query JSON non elaborate dai client

La scheda di riferimento OWASP afferma esplicitamente: "Non accettate query JSON non elaborate dai client." Un payload come { "$where": "this.balance > 0" } inviato da un client può portare all'esecuzione di codice da remoto o all'esaurimento delle risorse della CPU.

Configurate il database secondo il principio del privilegio minimo

Usate account di database dedicati alle applicazioni, con autorizzazioni minime. Non connettetevi mai con credenziali root o amministrative. Non esponete le porte del database o le console di amministrazione a Internet.

Mantenete attivo Wire Object Check

L'impostazione net.wireObjectCheck di MongoDB convalida tutti i documenti a livello di protocollo wire. È attiva per impostazione predefinita. Non disattivatela mai.

Proteggete i filtri GraphQL

Traducete gli argomenti dei filtri GraphQL tramite una lista esplicita di valori consentiti. Non inserite mai direttamente oggetti non attendibili nei filtri delle query MongoDB o Mongoose.

Controlli applicativi efficaci riducono la superficie di attacco. Non possono eliminarla del tutto: rilevamento e risposta su più livelli coprono ciò che sfugge ai controlli.

Strumenti di rilevamento e prevenzione

Una difesa su più livelli contro le iniezioni NoSQL combina controlli applicativi, strumenti di test e monitoraggio in fase di esecuzione.

• Le difese a livello applicativo includono librerie di convalida degli input (Joi, Ajv, Zod), protezioni a livello ORM (convalida degli schemi Mongoose, conversione esplicita dei tipi) e controlli di sicurezza integrati in MongoDB (--noscripting, wireObjectCheck, accesso basato sui ruoli).
• Gli strumenti di test come NoSQLMap, nosqli, Burp Suite e OWASP ZAP cercano vulnerabilità alle iniezioni NoSQL durante lo sviluppo e i cicli di penetration testing.
• I WAF aggiungono un livello di difesa perimetrale che può bloccare gli schemi di iniezione noti. Tuttavia, i WAF si basano su regole fondate su firme e non possono fermare payload nuovi, operatori offuscati o iniezioni tramite canali WebSocket.
• Il monitoraggio comportamentale in fase di esecuzione colma le lacune lasciate dai WAF. I controlli applicativi possono essere aggirati tramite payload nuovi, vulnerabilità a livello ORM come quella di Mongoose relativa a populate().match o canali WebSocket che i WAF non ispezionano. Il monitoraggio in fase di esecuzione rileva le conseguenze di un'iniezione riuscita, come processi del database che avviano shell inattese, schemi anomali di esecuzione JavaScript o volumi di query insoliti, indipendentemente da come sia stato recapitato il payload. Quando un payload di iniezione elude l'ispezione basata su firme e raggiunge il database, il comportamento anomalo che ne deriva diventa l'indicatore di compromissione più affidabile.

In che modo interviene SentinelOne?

L'ispezione dei payload spetta al WAF. SentinelOne osserva ciò che accade dopo: rileva e blocca le conseguenze comportamentali di un'iniezione NoSQL riuscita, dalle anomalie dei processi al movimento laterale e alle attività successive allo sfruttamento che sfuggono ai controlli applicativi.

La piattaforma di SentinelOne, Singularity™ Platform, include Singularity AI SIEM, che correla la telemetria di endpoint, workload cloud, sistemi di identità e fonti di terze parti in un unico data lake. Nelle MITRE ATT&CK Evaluations del 2024, Singularity Platform ha raggiunto il 100% di rilevamento senza ritardi, generando l'88% di alert in meno rispetto alla mediana. Meno rumore significa che il vostro team può concentrarsi sulle minacce confermate. Quando un attacco di injection NoSQL passa da un'applicazione web a un server di database fino al furto di credenziali, AI SIEM collega questi eventi tra le diverse superfici senza correlazione manuale.

All'interno di Singularity Endpoint, la tecnologia Storyline collega continuamente gli eventi di creazione dei processi, le connessioni di rete, le modifiche ai file e l'uso delle credenziali su ogni endpoint protetto, creando catene coerenti che ne tracciano l'origine. In un attacco basato su $where per eseguire JavaScript lato server, Storyline collega autonomamente il processo del server web che riceve la richiesta malevola, il servizio database che mostra un comportamento anomalo, il processo interprete avviato e qualsiasi shell figlia, tutti associati a un unico ID Storyline. Le regole personalizzate di Storyline Active Response (STAR) si attivano quando processi di database come mongod o redis-server avviano processi figli imprevisti, un indicatore comportamentale ad alta affidabilità di un'iniezione di comandi riuscita.

Purple AI™ accelera le indagini tramite query in linguaggio naturale. Secondo IDC, i clienti di Purple AI identificano le minacce il 63% più rapidamente e riducono del 55% il tempo medio di risoluzione (MTTR). Potete chiedere "mostrami tutti i processi avviati da mongod nelle ultime 24 ore" o fare riferimento direttamente a tecniche MITRE ATT&CK come T1190 (Exploit Public-Facing Application) e T1059 (Command and Scripting Interpreter). La funzionalità Auto Investigation di Purple AI raccoglie autonomamente prove nell'intero stack, sintetizza i dati sulle minacce e ricostruisce cronologie complete degli attacchi, riducendo a pochi minuti indagini che prima richiedevano ore.

Cloud Workload Security protegge durante l'esecuzione i database NoSQL ospitati nel cloud. Monitora il comportamento dei workload in tempo reale e usa Verified Exploit Paths per evidenziare i risultati supportati da prove. Potete vedere quando un'iniezione NoSQL contro un'istanza MongoDB o Redis ospitata nel cloud porta ad attività successive alla compromissione.

Per le organizzazioni che gestiscono database NoSQL su larga scala, queste funzionalità colmano il divario tra la prevenzione a livello applicativo e la visibilità sulle attività successive alla compromissione. 

Richiedete una demo di SentinelOne per vedere queste funzionalità in azione.

Vulnerabilità correlate

L'iniezione NoSQL condivide cause di fondo e schemi di attacco con diverse classi di vulnerabilità correlate:

• Iniezione SQL (CWE-89): La controparte nei database relazionali. Entrambe sfruttano la mancata neutralizzazione dell'input dell'utente nelle query ai database, ma la capacità dell'iniezione NoSQL di eseguire linguaggi procedurali estende l'impatto dalla manipolazione dei dati all'esecuzione di codice arbitrario.
• Server-Side Request Forgery (SSRF): L'iniezione CRLF in Redis viene spesso concatenata a SSRF. Un attaccante usa SSRF per raggiungere un'istanza Redis interna, poi inietta comandi aggiunti alla richiesta tramite sequenze CRLF.
• Iniezione di comandi (CWE-78): Quando l'iniezione NoSQL ottiene l'esecuzione di JavaScript lato server tramite $where, la capacità risultante è molto simile all'iniezione di comandi del sistema operativo.
• Prototype pollution: CVE-2022-24815 in Parse Server ha combinato prototype pollution e iniezione NoSQL, dimostrando come le vulnerabilità a livello JavaScript si sommino all'iniezione nei database.
• Cross-Site Scripting (XSS): sia XSS sia l'iniezione NoSQL derivano da una validazione insufficiente degli input. Le organizzazioni vulnerabili a una delle due presentano spesso debolezze sistemiche nella validazione che le espongono anche all'altra.

Comprendere queste relazioni vi permette di dare priorità ai test e alla correzione delle classi di vulnerabilità correlate, anziché trattarle singolarmente. La tabella seguente elenca, a titolo di riferimento, le CVE confermate relative all'iniezione NoSQL.