L’espressione Don’t Repeat Yourself (DRY) non è solo un principio di programmazione elegante, ma è anche una necessità di sicurezza.
Ogni volta che la stessa logica viene duplicata in punti diversi del codice, si crea una vulnerabilità sistemica che aspetta solo il momento giusto per manifestarsi. Il problema non è tanto la duplicazione in sé, ma è l’inevitabile divergenza che si crea nel tempo: modifiche, patch, aggiornamenti che vengono applicati in alcuni punti ma dimenticati in altri, e altre inconsistenze che gli attaccanti sanno sfruttare magistralmente.
La matematica della duplicazione è crudele: se hai la stessa validazione di sicurezza implementata in 5 punti diversi e c’è una probabilità del 5% di dimenticare un punto durante un aggiornamento, la probabilità che almeno uno rimanga vulnerabile è del 23%. Con 10 punti duplicati sale al 40%. Non è questione di competenza del team, ma di statistica pura: più copie esistono, più è probabile che una rimanga dimenticata o sfruttabile.
Ecco come trasformare il principio DRY da best practice di sviluppo a strategia di sicurezza operativa, fornendo ai responsabili della sicurezza metodologie per identificare duplicazioni pericolose nei sistemi esistenti, framework per centralizzare logiche critiche senza creare single point of failure, e processi di governance che prevengano la reintroduzione di codice duplicato in futuro[1].
L’esempio più comune di violazione DRY in ambito sicurezza riguarda la validazione dell’input. Un’applicazione web tipica può avere la stessa logica di validazione email implementata nel modulo di registrazione, nel form di contatto, nell’aggiornamento profilo, nel sistema di newsletter e nel pannello amministrativo. Sono cinque implementazioni della stessa regola, ognuna con piccole variazioni che possono sembrare innocue.
Quando emerge una nuova tipologia di attacco email-based (come, ad esempio, quello che sfrutta i caratteri Unicode per creare indirizzi apparentemente legittimi ma tecnicamente maligni), il team di sicurezza deve identificare e aggiornare tutti e cinque i punti.
Dimenticarne uno significa lasciare una backdoor aperta, spesso in sezioni dell’applicazione meno monitorate come, ad esempio, il pannello amministrativo o la newsletter.
I sistemi di autenticazione e autorizzazione rappresentano l’area più rischiosa per le violazioni del principio DRY. Quando la logica “verificare se l’utente può accedere a questa risorsa” viene duplicata in controller diversi, API endpoint separati, nonché middleware indipendenti, ogni copia diventa un potenziale punto debole per bypassare i controlli di sicurezza.
Un esempio reale: un’applicazione enterprise aveva implementato controlli di autorizzazione in 23 punti diversi. Durante un security assessment è emerso che 3 di questi punti utilizzavano una versione obsoleta della logica di controllo che permetteva di scalare i privilegi. Il bug era stato corretto negli altri 20 punti durante un aggiornamento precedente, ma questi 3 punti erano rimasti scoperti perché quelle parti di software venivano gestite da team indipendenti.
La crittografia rappresenta forse l’area più pericolosa per la duplicazione del codice. Quando algoritmi di hashing, encryption, decryption o signature verification vengono implementati in moduli separati, ogni copia può evolversi prendendo direzioni diverse. Una copia può essere aggiornata per utilizzare salt più lunghi, mentre un’altra copia può mantenere la versione vecchia, creando così inconsistenze che compromettono l’intero sistema.
Peggio ancora, quando vengono scoperti problemi in algoritmi crittografici come, ad esempio, la necessità di migrare da SHA-1 a SHA-256, la presenza di implementazioni duplicate rende quasi impossibile garantire che tutti i punti vengano aggiornati simultaneamente. Il risultato sono sistemi ibridi dove alcune parti utilizzano una crittografia robusta e altre rimangono vulnerabili.
I sistemi di logging e audit trail spesso violano il principio DRY in modi sottili ma pericolosi. La logica per registrare eventi di sicurezza critici (login falliti, accessi a dati sensibili, modifiche di configurazione) viene spesso implementata ad-hoc in ogni modulo che ne ha bisogno. Questa estemporaneità conduce a inconsistenze nel formato dei log, informazioni mancanti in alcuni punti e difficoltà nell’analisi forensica.
Quando un incidente di sicurezza richiede ricostruzione della timeline degli eventi, la presenza di sistemi di logging inconsistenti può rendere impossibile ottenere una visione completa di un evento o di un incidente. Alcune azioni critiche potrebbero non essere loggate, perché la loro implementazione è stata dimenticata durante lo sviluppo di nuove funzionalità.
La duplicazione non riguarda solo il codice, ma anche le configurazioni di sicurezza. Password policy, timeout di sessione, regole di firewall, configurazioni SSL/TLS: quando questi parametri vengono definiti in file multipli invece che centralizzati, ogni aggiornamento di sicurezza diventa un esercizio da caccia al tesoro per identificare tutti i punti da modificare.
Un caso tipico è quello di un’organizzazione che decise di aumentare la lunghezza minima delle password da 8 a 12 caratteri. Questa policy era configurata in 7 file diversi: web application, database, servizi Windows, sistemi Unix, VPN, WiFi enterprise e sistema di accesso fisico. Sei mesi dopo l’aggiornamento, un audit rivelò che 3 sistemi utilizzavano ancora la policy vecchia.
La duplicazione crea un fenomeno insidioso chiamato “configuration drift“: sistemi che dovrebbero essere identici divergono lentamente nel tempo a causa di aggiornamenti, patch e modifiche applicate in modo inconsistente. Questa divergenza non è sempre visibile durante operazioni normali, ma emerge drammaticamente durante un security assessment fatto da un ispettore di qualche Authority, o ancora peggio, durante un’incident response.
Il problema diventa esponenziale in ambienti distribuiti, dove la stessa applicazione viene deployata in datacenter multipli, cloud provider diversi o ambienti di staging/produzione separati. Ogni ambiente può sviluppare configurazioni di sicurezza leggermente diverse, rendendo quasi impossibile garantire una protezione uniforme.
La soluzione richiede approcci architetturali che centralizzano le logiche di sicurezza critiche. Authentication e Authorization dovrebbero essere gestite da servizi centralizzati (Identity Provider, Policy Decision Points) invece che essere implementate in ogni applicazione. La Validation Logic dovrebbe essere incapsulata in librerie condivise che garantiscano un comportamento consistente.
Configuration Management richiede principi di “Single Source of Truth“: ogni parametro di sicurezza dovrebbe essere definito in un unico punto e propagato automaticamente a tutti i sistemi che ne hanno bisogno. Infrastructure-as-a-Code e Configuration Management Systems permettono di implementare questo principio in modo sistematico: usiamoli!
Molte organizzazioni hanno sistemi legacy con duplicazioni estensive che non possono essere eliminate con una logica “big bang”, cioè di botto. Il refactoring sicuro richiede l’identificazione sistematica di tutte le duplicazioni attraverso analisi statica del codice e il configuration scanning, prioritizzazione basata sul rischio e migrazione graduale verso implementazioni centralizzate.
Il processo deve includere un testing rigoroso per garantire che la centralizzazione non introduca nuove vulnerabilità o single points of failure. Paradossalmente, eliminare duplicazioni può temporaneamente aumentare il rischio se il processo non viene gestito correttamente: un bug nella versione centralizzata può impattare simultaneamente tutti i sistemi.
Anche dopo aver eliminato eventuali duplicazioni esistenti, è necessario monitorare continuamente i sistemi e i codici in modo da prevenire la reintroduzione dei duplicati.
Le revisioni del codice dovrebbero includere controlli specifici per identificare logiche duplicate, l’automated testing dovrebbe verificare consistenza tra componenti e il configuration monitoring dovrebbe avvisare quando sistemi presumibilmente identici divergono.
La lotta contro la duplicazione non è un progetto estemporaneo, ma è un allenamento continuo che richiede disciplina, strumenti tecnologici e una cultura organizzativa che valorizzi la consistenza tanto quanto la funzionalità.
[1] Il Manuale CISO Security Manager prepara alla certificazione CISSP e fornisce metodologie per identificare ed eliminare problemi pericolosi in sistemi complessi, includendo strumenti di analisi automatica e framework di governance per mantenere principi DRY nel tempo.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Fabrizio Saviano
Source link
