Divulgazione del 3 novembre 2026
Descrizione
Nell’infrastruttura di sincronizzazione XDent/XMedical, componenti PHP accettavano modifiche dello stato di sessione da dati controllati dal client e inoltravano al database istruzioni SQL ricevute tramite HTTP. La combinazione avrebbe potuto consentire l’esecuzione di operazioni SQL senza un’autenticazione applicativa affidabile.
Componenti interessati
L’advisory riguarda l’infrastruttura centralizzata di sincronizzazione utilizzata dai prodotti XDent e XMedical e le funzionalità di sessione e accesso SQL descritte nel finding DB-1.
- Livello applicativo PHP del servizio di sincronizzazione XDent/XMedical.
- Gestione dello stato di sessione e dei controlli di autenticazione applicativa.
- Funzionalità HTTP che ricevevano istruzioni SQL e ne richiedevano l’esecuzione a MySQL.
- Connessione al database utilizzata dal servizio e autorizzazioni sugli archivi accessibili.
Causa della vulnerabilità
Il confine tra input del client e stato di autenticazione non era protetto adeguatamente: un componente permetteva di assegnare variabili di sessione a partire da parametri della richiesta, compreso lo stato impiegato per riconoscere l’utente come autenticato. Altre funzionalità applicative ricevevano SQL dal client e lo inoltravano al database. Una decisione di fiducia modificabile dall’esterno, associata a un’interfaccia capace di eseguire istruzioni generiche, avrebbe potuto trasferire a un richiedente non autorizzato le capacità dell’account database del servizio.
Analisi tecnica
Stato di sessione controllabile dal client
La gestione della sessione PHP comprendeva un componente che accettava assegnazioni di variabili attraverso parametri HTTP. Tra i valori modificabili rientrava quello utilizzato dall’applicazione per rappresentare lo stato di autenticazione. Il server non manteneva quindi una separazione affidabile tra i dati forniti dal richiedente e la decisione di considerarlo autenticato.
Chi fosse riuscito a modificare quel valore avrebbe potuto ottenere un contesto di sessione trattato come autenticato senza completare il normale processo di verifica dell’identità. La protezione di una funzionalità che si fosse affidata esclusivamente a quel contesto avrebbe potuto risultare aggirabile.
Istruzioni SQL ricevute tramite HTTP
Le funzionalità coinvolte accettavano istruzioni SQL da parametri della richiesta e ne chiedevano l’esecuzione al database. L’interfaccia non limitava il client a un insieme di operazioni applicative predefinite e autorizzate. Il contenuto controllato dal richiedente poteva così determinare l’operazione da eseguire, anziché fornire soltanto valori per una query stabilita dal server.
La correzione di questo percorso richiede di eliminare l’esecuzione di SQL generico ricevuto dal client. La parametrizzazione dei valori rimane necessaria nelle interrogazioni applicative, ma non sostituisce la rimozione di un’interfaccia che attribuisca al client la scelta dell’intera istruzione. Autenticazione e autorizzazione devono inoltre essere verificate sul server per ogni operazione.
Privilegi della connessione e portata delle operazioni
La connessione applicativa a MySQL utilizzava un account con privilegi elevati. Le istruzioni elaborate dall’interfaccia HTTP venivano eseguite nel contesto di tale account; i privilegi erano quindi quelli del servizio, anziché quelli specifici del richiedente o di una singola operazione applicativa.
Un utilizzo non autorizzato avrebbe potuto permettere la lettura degli archivi accessibili e, quando consentito dai permessi, operazioni di scrittura, cancellazione o modifica della struttura del database. L’estensione a più archivi sarebbe dipesa dalle autorizzazioni assegnate all’account. Queste condizioni riguardano l’esecuzione SQL: non comportano automaticamente l’esecuzione di comandi sul sistema operativo.
Accesso attraverso il livello web
Il percorso descritto attraversava il servizio HTTP e la sua connessione applicativa al database. La raggiungibilità diretta del protocollo MySQL da parte del richiedente non era quindi un prerequisito dell’esecuzione SQL attraverso l’applicazione.
Una limitazione delle connessioni dirette al database avrebbe potuto ridurre altre modalità di accesso, ma non avrebbe corretto un servizio web autorizzato a connettersi a MySQL che continuasse ad accettare operazioni da richiedenti non autenticati. È necessario applicare i controlli nel punto in cui il servizio riceve e autorizza la richiesta.
Categorie di informazioni potenzialmente interessate
Gli archivi descritti nel finding comprendevano anagrafiche dei pazienti, note cliniche, anamnesi, allergie, prestazioni, piani di trattamento e documentazione odontoiatrica. Erano inoltre documentati riferimenti a immagini cliniche, consensi e referti, fatturazione e configurazioni degli studi. Si tratta di categorie di informazioni ricavate dalla struttura applicativa e dei dati, senza riprodurre record reali.
L’accesso SQL avrebbe potuto esporre i campi leggibili con i privilegi della connessione e permettere di associare dati anagrafici e sanitari. Per i campi cifrati, l’effetto sarebbe dipeso anche dalla disponibilità delle funzioni e del materiale necessari alla decifratura nel contesto raggiungibile. La presenza di un riferimento a un file o a un’immagine nel database non equivale, da sola, alla possibilità di acquisirne il contenuto attraverso la stessa interfaccia.
Prerequisiti e condizioni
- Il servizio applicativo coinvolto deve essere raggiungibile e rendere disponibili le funzionalità di sessione e accesso SQL interessate.
- Il percorso vulnerabile non richiedeva una credenziale applicativa legittima. Eventuali filtri di rete o controlli compensativi sul servizio avrebbero potuto incidere sulla raggiungibilità del percorso.
- Le operazioni SQL avrebbero avuto la portata consentita dai privilegi della connessione del servizio; scrittura, cancellazione e accesso a più archivi richiedono i rispettivi permessi.
Impatto potenziale
Un soggetto non autenticato che fosse riuscito a utilizzare queste funzionalità avrebbe potuto eseguire istruzioni SQL con i privilegi dell’account impiegato dal servizio. Ciò avrebbe potuto consentire la lettura di dati clinici, anagrafici, amministrativi e di configurazione e, in presenza dei relativi permessi, la modifica o cancellazione dei dati e delle strutture del database. L’eventuale accesso a più archivi sarebbe dipeso dalle autorizzazioni di quell’account. Operazioni distruttive avrebbero potuto compromettere la disponibilità della sincronizzazione e l’integrità delle informazioni gestite dagli studi.
Indicazioni di mitigazione
Applicare la correzione indicata dal fornitore e verificare che il servizio non accetti modifiche dello stato di autenticazione né istruzioni SQL generiche provenienti da client non autorizzati. Gli interventi devono riguardare il livello HTTP e il modello di autorizzazione del servizio, oltre ai privilegi della connessione al database.
- Rimuovere o disabilitare i componenti che accettano assegnazioni arbitrarie delle variabili di sessione; lo stato di autenticazione deve essere stabilito e mantenuto dal server.
- Eliminare l’esecuzione di istruzioni SQL generiche ricevute dai client e sostituirla con operazioni applicative predefinite, autorizzate singolarmente.
- Usare query parametrizzate per i valori delle operazioni ammesse e verificare l’autorizzazione rispetto allo studio e alle risorse richieste.
- Limitare i privilegi degli account database alle operazioni e agli archivi necessari, separando le funzioni amministrative da quelle del servizio.
- Applicare le restrizioni di rete previste per la sincronizzazione e mantenere il database raggiungibile soltanto dai componenti che ne hanno necessità.
- Verificare che la correzione rifiuti richieste senza autenticazione, modifiche esterne dello stato di sessione e operazioni SQL non previste; controllare anche le richieste verso archivi non autorizzati.
- Conservare registrazioni adeguate delle autenticazioni e delle operazioni autorizzate o rifiutate, evitando di includere credenziali, token o dati clinici nei log.
Stato della correzione
Risoluzione dichiarata dal fornitore
Il fornitore ha comunicato la risoluzione della vulnerabilità compresa in questo advisory. Il ricercatore non ha potuto verificare le patch, poiché il fornitore non ha offerto questa possibilità. La risoluzione resta pertanto una dichiarazione del fornitore e non una verifica indipendente del ricercatore.
Fonte e aggiornamento
Documentazione tecnica di ricerca XDent/XMedical del 23 giugno 2026 e finding DB-1 della segnalazione del 24 giugno 2026. Le descrizioni riguardano le condizioni precedenti alle correzioni dichiarate dal fornitore.
Aggiornamento della scheda: 3 novembre 2026.
Metodo e divulgazione
La scheda descrive le condizioni documentate nella ricerca sui componenti e sugli artefatti del software. I possibili effetti dipendono dai prerequisiti e dai controlli indicati; lo stato della correzione è riportato separatamente. Sono pubblicati soltanto i finding con pubblicabilità confermata, senza credenziali, chiavi o istruzioni di sfruttamento.
Per riscontri tecnici, indicazioni sulle versioni corrette o richieste di rettifica: contatta l’Osservatorio.