Segnalazione di vulnerabilità
Se hai trovato un problema di sicurezza in InTasca, questa pagina spiega come dircelo e cosa succede dopo.
Le segnalazioni di sicurezza vanno all'indirizzo dedicato security@intascanapoli.com. Lo stesso recapito è pubblicato, nel formato leggibile dalle macchine previsto dalla RFC 9116, in /.well-known/security.txt. Non usare i canali di assistenza ordinari né i social: una segnalazione di sicurezza deve restare riservata finché il problema non è risolto.
Per poter riprodurre e correggere il problema in fretta ci servono:
- una descrizione del problema e del suo impatto (quali dati o funzioni sono esposti, a chi);
- i passi per riprodurlo: URL, richieste, parametri, ruolo dell’utente usato;
- la data e l’ora della prova, così possiamo ritrovarla nei nostri registri;
- eventuali schermate o registrazioni, senza dati personali di terzi;
- come preferisci essere ricontattato e se vuoi essere citato nella correzione.
Se durante la ricerca hai avuto accesso a dati che non ti appartengono, fermati, non scaricarli, non modificarli e non condividerli: descrivili nella segnalazione e cancellali dopo il nostro riscontro.
- confermiamo la ricezione entro 5 giorni lavorativi;
- valutiamo la gravità e ti diciamo se e quando prevediamo di correggere;
- ti avvisiamo quando la correzione è in produzione;
- se la vulnerabilità riguarda dati ricevuti da piattaforme terze (per esempio Meta o Google), lo comunichiamo anche a loro nei termini previsti dai rispettivi accordi per sviluppatori.
INTASCA S.r.l.s. non intraprenderà azioni legali contro chi ricerca e segnala una vulnerabilità in buona fede, rispettando queste regole: nessun accesso a dati oltre il minimo necessario a dimostrare il problema, nessuna interruzione del servizio, nessuna divulgazione pubblica prima della correzione o, in ogni caso, prima di 90 giorni dalla segnalazione salvo diverso accordo.
- esiti di scanner automatici senza una prova di sfruttabilità;
- attacchi di ingegneria sociale o fisici verso il personale o i fornitori;
- denial of service o test di carico;
- problemi in servizi di terzi (Meta, Google, Cloudflare, Hetzner) che non dipendono dalla nostra configurazione: vanno segnalati a loro.
- ogni azienda è separata dalle altre a livello di database (Row Level Security di PostgreSQL in modalità FORCE su 217 tabelle) e ogni riga porta l’identificativo dell’azienda;
- l’autenticazione in due passaggi (TOTP) è disponibile per ogni utente ed è obbligatoria per i titolari e gli amministratori di ogni azienda; le password sono conservate con argon2id; i tentativi di accesso sono limitati per email e per indirizzo IP;
- i token dei servizi collegati, i segreti della verifica in due passaggi, gli IBAN dei dipendenti e gli XML delle fatture sono cifrati a riposo con AES-256-GCM; il traffico è sempre su TLS con HSTS;
- il registro di audit è una catena immutabile (HMAC-SHA256) verificata ogni giorno; gli accessi con poteri di piattaforma vi sono registrati;
- il database è copiato ogni giorno su un archivio fuori sede in giurisdizione UE, immutabile per 30 giorni (copie mensili: 365) e cifrato a riposo dal servizio di archiviazione; una prova di ripristino è eseguita almeno ogni 90 giorni;
- i server sono in Finlandia (UE, data center di Helsinki), dietro proxy e protezione DDoS di Cloudflare, raggiungibili solo con chiavi SSH; le intestazioni HTTP di sicurezza (CSP, X-Frame-Options, HSTS) sono applicate a ogni risposta;
- una violazione dei dati è comunicata all’azienda interessata entro 24 ore da quando ne veniamo a conoscenza, con l’assistenza per la notifica al Garante.
Il dettaglio di ogni misura, con il file del codice che la realizza, sta nell'Accordo sul trattamento dei dati, capitolo 5; i cookie e la memoria locale usati dalla piattaforma sono elencati nell'Informativa privacy, capitolo 10-bis.