Divulgazione responsabile delle vulnerabilità
Ogni software ha dei bug. I nostri preferiamo che li trovi tu.
Questo è il programma di divulgazione delle vulnerabilità di diagnos. Non paghiamo in denaro — oggi non possiamo. Paghiamo in gratitudine pubblica, con un posto nella hall of fame e con la certezza che l'esame di qualcuno è diventato più sicuro grazie al tuo contributo.
curl https://diagnos.health/.well-known/security.txt Contact: mailto:[email protected]Contact: mailto:[email protected]Policy: https://diagnos.health/en/bounty/Preferred-Languages: pt-BR, en, es, it, frExpires: 2027-09-16T00:00:00Z Accesso rapido
Le dieci sezioni di questa pagina, per aprire subito quella che cerchi.
Hall of fame
Ogni vulnerabilità valida finisce in questa lista, con il nome che scegli tu — il tuo nome, il tuo nickname, la tua @ o nessuno dei tre.
| # | Ricercatore | Cosa ha trovato | Quando |
|---|---|---|---|
| 001 | TU | questa riga è riservata | quando vuoi |
| 002 | — | — | — |
| 003 | — | — | — |
| 004 | — | — | — |
| 005 | — | — | — |
VOGLIO TE
PER LA SICUREZZA DI DIAGNOS
Postura di sicurezza
Controlli attivi in produzione
-
La tua password non arriva mai da noi
Il login gira su OPAQUE, un PAKE: il server non vede mai la tua password, nemmeno durante il login. Conserva solo un registration_record, che da solo non apre nulla.
-
Il server non può aprire il tuo caveau
Le chiavi nascono sul tuo dispositivo. Il server riceve solo testo cifrato — non esiste una riga di codice dall'altra parte che apra una KEK.
-
Ripetere una richiesta non funziona
Ogni richiesta sensibile porta nonce + timestamp, chiave primaria (scope_id, ts, nonce) su D1, tolleranza di orologio di 120s e retention di 300s ripulita da un cron.
-
Ogni richiesta rilevante diventa un record
Scriviamo un oggetto per ogni richiesta rilevante su R2. La scrittura è a pagamento e gira fuori dal percorso critico della risposta — controllare non rallenta nessuno.
-
Il dominio più sensibile è il più blindato
sign.diagnos.health ha una CSP default-src 'none' vera — blocca, non solo segnala — e SRI calcolato in build. Il cookie del dispositivo è __Host-, HttpOnly, Secure, SameSite=Strict.
-
Il dato clinico sa dove abita
Referti e immagini stanno in un bucket R2 con giurisdizione UE legata direttamente al binding — non è una promessa contrattuale, è una configurazione che l'infrastruttura applica.
Lacune note
- Non abbiamo mai assunto un penetration test indipendente. Nessuno dall'esterno ha ancora verificato questo sistema.
- Non abbiamo SOC 2 né ISO 27001.
- HIPAA: i requisiti tecnici sono coperti, ma la catena di contratti con i subprocessor (BAA) è incompleta — solo due firmati, il resto in negoziazione.
- La CSP dell'app è ancora in modalità report-only: segnala la violazione, non blocca nulla.
- La scansione automatizzata delle vulnerabilità avviene ancora in modo occasionale, non come routine continua.
- L'interruttore del rate limit è una stima prudente, mai calibrata su traffico reale di produzione.
La prima lista è quello che abbiamo già costruito. La seconda è il motivo per cui questa pagina esiste. Non ti stiamo chiedendo fiducia — ti stiamo chiedendo diffidenza, messa nero su bianco in un report.
Ambito del programma
Nove possibili obiettivi. L'etichetta accanto a ciascuno dice se è dentro, fuori, o dentro-ma-con-nota-a-piè-di-pagina — leggila prima di puntare qualsiasi strumento verso uno di essi.
| Obiettivo | Stato | Cos'è |
|---|---|---|
| vault.diagnos.health | Nell'ambito | Il server principale del prodotto — il "caveau". Sessione, sblocco via OPAQUE, il ledger, URL firmati di R2, Agenti IA, MCP e OAuth passano tutti da qui. |
| api.diagnos.health | Nell'ambito | Lo stesso server, con l'altro nome che il prodotto usa per lui. Oggi le due voci convivono nel codice — valgono entrambe. |
| /api/internal/v1/* | Dentro, con una nota | Un prefisso dentro l'API stessa, riservato all'app ufficiale — richiede header che un curl da solo non produce. Leggi l'avviso qui sotto prima di testare questa riga. |
| sign.diagnos.health | Nell'ambito | La cerimonia di firma del referto — WebAuthn/passkey, raggiunta tramite link o codice QR. Il dominio più sensibile del prodotto. |
| app.diagnos.health | Nell'ambito | L'app web di diagnos. |
| diagnos.health | Nell'ambito | Questo sito, quello che stai leggendo adesso. È nell'ambito anche se è marketing statico — ma modera le aspettative: il peggio che puoi trovare qui è un redirect aperto. |
| SDK · CLI · API Apache-2.0 | Nell'ambito | SDK, CLI e API in Python, licenza Apache-2.0. Il codice arriverà presto in un repository pubblico — leggerlo è benvenuto. |
| *.diagnos.health | Fuori dall'ambito | Qualsiasi *.diagnos.health non presente in questa lista è fuori dall'ambito e fuori dal safe harbor. È lo standard reso popolare da GitHub: possiamo autorizzare ricerca solo sui sistemi che sono nostri. |
| cloudflare · google · modal · sentry · … | Fuori dall'ambito | Cloudflare, Google/Firebase, Modal, Sentry e simili. Segnalalo a loro, non a noi — a meno che il problema non sia chiaramente nella nostra integrazione. |
Sull'audience "internal" (e perché il curl da solo non basta)
Header richiesti
L'audience internal richiede, tutti insieme:
Authorization: Bearer <Firebase ID token>X-AppCheck-TokenX-Signature-HmacX-Signature-NonceX-Signature-Timestamp
Quello che non esiste
- Non esiste X-Device-Challenge. Il nome è circolato internamente, ma non è mai esistita una riga di codice con questo nome.
- Non esiste un blocco automatico del workspace. Nessuna chiamata sbagliata blocca da sola un account — anche questo è circolato, ed è altrettanto falso.
Quello che esiste davvero
Quello che esiste davvero, e dice la stessa cosa:
- Limite di richieste per rotta, più un interruttore per ambito: 600 richieste per finestra.
- Anti-replay vero: chiave primaria (scope_id, ts, nonce) — un nonce ripetuto restituisce 409, non 401.
- Freno anti brute-force sul login: 10 tentativi in 15 minuti per account, best-effort.
- Ogni 4xx/5xx diventa un segnale di sicurezza anonimo; quelli ad alta gravità aprono un'eccezione che una persona rivede prima di qualsiasi blocco.
Testa l'audience internal attraverso l'app web, con il tuo account: gli header nascono da soli, e tutto quello che fai lì è nell'ambito e coperto dal safe harbor. Martellare /api/internal/v1/* direttamente con curl non prova nulla oltre una collezione di 401 — e genera solo rumore che qualcuno dovrà smistare a mano.
Dati dei pazienti
Cosa non fare
- Non aprire l'esame.
- Non scorrere la pagina.
- Non fare uno screenshot.
- Non copiare l'ID "per controllarlo dopo".
Cosa fare
- Segnalalo subito, con il minimo dettaglio necessario a dimostrare che il problema esiste.
- La proof of concept dimostra l'accesso, mai il contenuto — per esempio: "sono riuscito a elencare i record di altri workspace tramite l'endpoint X cambiando il parametro Y", senza incollare il referto.
- Cancella ogni copia locale: cache, screenshot, cronologia di Burp, log del proxy.
- Non esfiltrare, scaricare, condividere, pubblicare o cercare di monetizzare mai dati di pazienti — nemmeno per dimostrare l'impatto.
Base giuridica
Il dato sanitario è un dato personale sensibile ai sensi della LGPD, la legge brasiliana sulla protezione dei dati (art. 5, II combinato con l'art. 11).
E il §4 dell'art. 154-A del Codice Penale brasiliano aumenta la pena da 1/3 a 2/3 per chi divulga, commercializza o trasmette a terzi i dati ottenuti — anche quando l'accesso iniziale era autorizzato. In altre parole: il safe harbor di questa policy copre l'essere entrati; non copre l'aver portato via qualcosa.
Tem uma consequência que é sua, não só nossa: quem decide o que fazer com o dado é, por definição, o controlador dele. Se você baixar, guardar ou compartilhar o que achou, você deixa de ser alguém testando o sistema e vira isso sozinho — respondendo direto perante o titular nos termos dos dois regimes, sem cobertura nenhuma desta política. E tirar esse dado do bucket europeu para qualquer outro lugar também é transferência internacional de dado pessoal, com regime próprio nos dois lados: LGPD, arts. 33 a 36; GDPR, Capítulo V, arts. 44 a 49.
E se o que você achou não é uma falha em potencial, mas exposição que já aconteceu, o seu relatório é o que dispara, para nós, o prazo legal de notificar a autoridade e o titular — até 72 horas pelo GDPR (Art. 33), até 3 dias úteis pela LGPD (Resolução CD/ANPD nº 15/2024). É por isso que pedimos para reportar na hora, em vez de continuar investigando atrás de um achado mais completo.
Non è burocrazia. È che dall'altra parte di quel JSON c'è un risultato di biopsia con nome e cognome.
Regole di partecipazione
Durante il test
- Testare con i tuoi account di prova, o account creati da te.
- Usare strumenti automatizzati — scanner, fuzzer — con buon senso.
- Fermarti al primo segnale di un dato reale di paziente e segnalarlo.
- Accedere, o tentare di accedere, all'account di un'altra persona.
- Fare un DoS volumetrico, o puntare uno scanner che spara migliaia di richieste al minuto contro la produzione — riversare traffico non è ricerca, è abuso.
- Usare ingegneria sociale contro il nostro team, i nostri pazienti o i nostri partner.
- Compiere un attacco fisico.
Fermarsi non è un suggerimento — è la regola più importante di questa pagina. Il dettaglio completo è in Dati dei pazienti.
Uso dell'IA nei report
- Usare l'IA per esplorare o scrivere va bene — non facciamo finta che non esista. Ma rispondi tu per ogni parola e ogni affermazione tecnica del report, generata dall'IA o no.
- Dichiara esplicitamente se uno strumento di IA ha aiutato.
- Ogni report richiede una proof of concept che funzioni davvero, riprodotta da te. L'output di uno scanner o di un LLM senza conferma manuale non è una vulnerabilità — è un'ipotesi, e un'ipotesi non verificata viene chiusa come non valida.
Un report fabbricato, esagerato o con una PoC che non si riproduce viene chiuso senza risposta dettagliata. La recidiva porta al bando dal programma.
Nel gennaio 2026, il progetto curl ha chiuso l'intero programma di bug bounty dopo che i report generati dall'IA hanno iniziato a superare di gran lunga quelli validi. In anni di monitoraggio, nessun report prodotto solo dall'IA, senza verifica umana, ha mai trovato una vulnerabilità reale.
Non vogliamo arrivare lì.
Tempi di gestione
-
Conferma
Confermiamo la ricezione del tuo report entro 5 giorni lavorativi.
-
Triage
Valutiamo la gravità e ti diciamo qual è il seguito.
-
Correzione
Lavoriamo alla correzione con priorità proporzionale alla gravità.
-
Avviso
Ti avvisiamo quando la correzione viene pubblicata.
-
Riconoscimento
Offriamo un credito pubblico facoltativo — e non ci vendichiamo mai contro la ricerca in buona fede.
La scala completa di gravità e priorità è nella sezione Classificazione della gravità.
Divulgazione pubblica
Chiediamo 90 giorni di calendario contati dalla conferma del problema — non dall'invio, che è una data che controlli solo tu — prima di qualsiasi pubblicazione.
Se la correzione esce prima, possiamo concordare una data di divulgazione congiunta anticipata.
Se il problema è sfruttato attivamente da terzi in questo momento, quel termine si accorcia — avvisaci subito.
E non pubblicare mai dati di pazienti, credenziali reali o qualsiasi cosa che aumenti il rischio, anche dopo la scadenza.
Safe harbor legale
In pratica, ci impegniamo a:
- Non avviare né sostenere alcuna azione civile, denuncia penale o segnalazione alla polizia contro di te per la ricerca condotta secondo questa policy — incluse le misure tecniche usate per accedere a un sistema in ambito.
- Se un terzo ti minaccia o avvia un'azione legale per quella ricerca, dichiarare pubblicamente e formalmente che la tua condotta è stata ricerca di sicurezza autorizzata e in buona fede.
E questo ha dei limiti, visibili quanto la promessa:
- Vale solo per i sistemi elencati in Ambito. Non possiamo autorizzare ricerca su un sistema di terzi, anche se raggiungibile dal nostro.
- Non copre condotte fuori dall'ambito o dalle regole di questa policy.
- Non copre il portare via dati. Accedere per testare è una cosa; estrarre è un'altra — vedi Dati dei pazienti e il §4 dell'art. 154-A, che aggrava la pena proprio per questo.
- Non si applica a ricerca condotta per estorcere o costringere qualcuno, né a chi è escluso in Riconoscimento.
Ci stai testando da fuori del Brasile? Questa autorizzazione resta comunque fondata sulla legge brasiliana — è quella che governa i sistemi che toccheresti. Per cortesia, consideriamo questa policy anche come un'autorizzazione di accesso in buona fede secondo la legge sui reati informatici applicabile nel tuo paese.
Non sei sicuro se un test specifico rientri in questa policy? Chiedi prima, a [email protected].
Fondamento legale in Brasile
In Brasile non esistono "CFAA" né "DMCA". Sono leggi statunitensi, e incollare quella sigla in una policy brasiliana non protegge nessuno qui — dice solo che il testo è stato tradotto, non pensato.
Quello che si applica è l'art. 154-A del Codice Penale brasiliano (Legge n. 12.737/2012, modificata dalla Legge n. 14.155/2021). Rende reato violare un dispositivo informatico altrui "senza autorizzazione espressa o tacita" di chi lo usa.
C'è un dettaglio che cambia tutto. Il testo del 2012 si applicava solo quando la violazione avveniva "mediante violazione indebita di un meccanismo di sicurezza" — bisognava rompere qualche protezione. La Legge n. 14.155/2021 ha eliminato questo requisito. Oggi il reato non dipende più dal rompere qualcosa: dipende solo dall'agire senza autorizzazione. L'autorizzazione è diventata l'unico elemento decisivo.
Per questo questa pagina è l'autorizzazione espressa di cui parla la legge. Ed è più forte di una promessa di non denunciarti: con l'autorizzazione, il reato non arriva nemmeno a esistere — non è una difesa successiva, è l'assenza di un elemento del reato stesso. Una condotta autorizzata non diventa mai reato.
Segnalazioni non ammissibili
Non è che non ci importi — è che senza un impatto dimostrato non si riesce a distinguerlo dal rumore di fondo.
Configurazione e header
- Header di sicurezza assente (CSP, HSTS, X-Frame-Options) senza una PoC di sfruttamento reale.
- Record SPF, DKIM o DMARC assente o mal configurato.
- Divulgazione della versione del software in un banner, header o changelog pubblico, senza sfruttamento associato.
- Assenza di certificate pinning in un'app mobile.
Interfaccia e interazione
- Clickjacking su una pagina che non esegue alcuna azione sensibile.
- Self-XSS — la vittima deve incollare da sé il payload.
- Redirect aperto senza impatto aggiuntivo dimostrato.
Enumerazione e limiti di velocità
- Enumerazione di utente o email — scoprire se esiste un account.
- Assenza di rate limiting senza prova di un brute-force realizzabile.
- CSV injection senza esecuzione comprovata nell'ambiente della vittima.
Infrastruttura e disponibilità
- Denial of service volumetrico, o qualsiasi cosa che dipenda dal generare traffico massiccio.
- Un attacco che richiede di intercettare il traffico di qualcun altro, senza una falla nostra che lo renda possibile.
Terze parti e dipendenze
- Una falla in una libreria di terze parti, senza una PoC di sfruttamento specifico nel nostro ambiente.
- Una falla in un servizio o in un'infrastruttura che non gestiamo noi.
Qualità del report
- Output di uno scanner senza PoC manuale e senza conferma di sfruttamento reale.
- Report generato dall'IA senza verifica umana e senza PoC riproducibile.
Fuori dal modello di minaccia
- Ingegneria sociale contro il nostro team, i nostri partner o i nostri pazienti.
- Attacchi fisici contro un ufficio, un dipendente o un dispositivo.
- Un bug che si manifesta solo su un browser o un sistema operativo obsoleto, non più supportato dal produttore.
- Un attacco che dipende dal fatto che la vittima segua le istruzioni dell'attaccante stesso — incollare un comando, installare un'estensione.
Pensi che il tuo caso sia l'eccezione? Mandalo comunque e spiega il perché. Questa lista è un filtro, non un muro.
Classificazione di severità
La gravità decide una cosa sola: l'ordine nella coda delle correzioni. Nient'altro.
| Gravità | Criterio generale | Esempi in diagnos |
|---|---|---|
| Critica | Compromette la riservatezza di più di un paziente, o rompe la garanzia centrale della cifratura end-to-end — senza bisogno che la vittima clicchi su nulla. |
|
| Alta | Compromette i dati di un solo workspace, o concede privilegi di amministratore al suo interno — ancora senza interazione della vittima. |
|
| Media | Ha un impatto reale, ma limitato: richiede un clic della vittima, oppure espone metadati invece del contenuto del referto. |
|
| Bassa | Impatto minimo, richiede condizioni improbabili tutte insieme, oppure è solo informativo — senza un percorso chiaro fino a un dato del paziente. |
|
La classificazione finale è nostra — ma spieghiamo il ragionamento. Se non sei d'accordo, dillo: la rivalutiamo.
Riconoscimento e ammissibilità
Quattro cose, in quest'ordine — la prima fa un po' male.
-
Soldi: zero.
Niente "lo stiamo valutando". Zero, davvero. Siamo un'azienda piccola, e i soldi che ci sono pagano server e persone. Se un giorno cambierà, cambia anche questa pagina — e lo saprai tra i primi.
-
Credito prodotto, forse.
Possiamo — a nostra discrezione e senza alcun obbligo — offrire credito d'uso della piattaforma. Senza valore concordato, senza garanzia, non negoziabile. Non è un pagamento: è gratitudine con una fattura intorno.
-
Un posto nella hall of fame.
Ogni vulnerabilità valida entra — con il nome che scegli: il tuo nome vero, un soprannome, un @ di un social o anonimo.
Vedi la hall of fame -
La gratitudine di chi non conoscerai mai.
Dall'altra parte ci sono medici e pazienti che non sapranno mai il tuo nome. È poco. Lo sappiamo che è poco. Ma è vero.
E chiediamo una cosa in cambio: il permesso di citare il tuo report — tecnico, senza dati di pazienti — nel nostro changelog di sicurezza, quando la correzione sarà pubblicata.
Chi può partecipare
Chiunque può segnalare, e correggiamo comunque. Quello che cambia è il credito — niente riconoscimento pubblico né credito prodotto per:
- Chi lavora o ha lavorato in MedDeck negli ultimi sei mesi — fornitori inclusi.
- Familiare diretto di chi ha informazioni privilegiate sul sistema testato.
- Persona o entità in una lista di sanzioni (OFAC/SDN, Unione Europea) o in un paese sotto embargo totale.
- Chi è arrivato alla falla per violazione di contratto o fuga di informazioni interne, e non per ricerca indipendente.
Come inviare una segnalazione
La maggior parte delle segnalazioni arriva dalla casella standard. L'altra esiste per quando aspettare costerebbe davvero caro.
Il canale standard
Ogni segnalazione arriva qui — è la casella che leggiamo per prima, sempre.
Invia una segnalazioneSolo quando aspettare costa caro
Sfruttamento attivo in corso proprio ora. Dati di un paziente già esposti pubblicamente. Una credenziale trapelata. Questa casella è per questo — e solo per questo.
Questo non può aspettare Cosa deve contenere la segnalazione
- Passaggi di riproduzione numerati, nell'ordine in cui li hai davvero fatti.
- L'impatto reale — cosa può FARE un attaccante, non solo "sono riuscito a ottenere X".
- Ambiente, browser e account che hai usato.
- Una proof of concept minima e non distruttiva.
Non deve essere in inglese, né formattata come un CVE. La chiarezza conta più della formalità.
Tieni tutto sul canale privato con noi finché non concordiamo insieme la divulgazione pubblica.
Il file che fa questo lavoro al posto tuo. È già online, ed è così che uno strumento automatico ci trova prima che un essere umano legga questo: /.well-known/security.txt
Segnalazioni cifrate
Non abbiamo ancora pubblicato una chiave PGP. Vuoi cifrare comunque? Chiedicelo via email e ti mandiamo come fare.
Domande frequenti
Non pagate davvero niente?
Niente. Né soldi, né cripto, né una maglietta. Possiamo offrire credito prodotto quando ha senso, senza alcuna garanzia — è gratitudine con un limite, non un prezzo travestito.
Posso testare con il mio account vero?
Puoi, ed è il modo consigliato se fai parte del pubblico interno — vedi la sezione "Ambito". Quello che non puoi mai fare, in nessun caso, è testare con l'account di qualcun altro.
Ho trovato dati di un paziente. E adesso?
Fermati. Non aprire l'esame, non scorrere, non copiare l'ID "per confermare dopo". Segnala il ritrovamento senza incollare il contenuto del referto — la sezione "Dati dei pazienti" ha il passo dopo passo, e non è burocrazia: è la differenza tra ricerca sulla sicurezza e reato.
Quanto tempo prima che qualcuno risponda?
Confermiamo la ricezione entro 5 giorni lavorativi; dopo, ti diamo una posizione su gravità e passi successivi. È un obiettivo di servizio che ci imponiamo da soli, non una clausola SLA contrattuale.
Posso pubblicare quello che ho trovato?
Sì — 90 giorni di calendario dopo la conferma del problema, o prima se concordiamo insieme una data. Mai con dati di pazienti dentro, anche dopo la scadenza.
Ho usato l'IA per trovarlo. C'è un problema?
Nessuno, purché tu l'abbia verificato e riprodotto di persona, in un ambiente reale. Un output dell'IA senza questa verifica non è una vulnerabilità, è un'ipotesi — la sezione "Regole" spiega perché.
Mi farete causa?
No, se hai seguito questa politica. La sezione "Safe harbor" è, in una frase, l'autorizzazione espressa che l'art. 154-A del Codice Penale brasiliano richiede perché quello che stai per fare non sia reato — non è retorica, è il testo della legge.
Ho già segnalato e non ho avuto risposta.
Rimanda menzionando la data del primo invio — le email si perdono. Se è davvero urgente, usa la casella di urgenza. Non è indifferenza: siamo un team piccolo, non un centro operativo di sicurezza 24 ore su 24.
È tutto. Vai pure.
Se sei arrivato fin qui, i dati di questi pazienti ti stanno già a cuore più che a molte persone che ci lavorano ogni giorno. Grazie — e buona caccia.
Segnala una vulnerabilità