Tecniche di code review sicura

La revisione di sicurezza del codice individua le vulnerabilità nel codice sorgente prima della distribuzione. A differenza della revisione funzionale del codice, si concentra sui confini di fiducia, sui flussi di dati, sulle API pericolose, sui controlli mancanti e sugli errori nella logica di sicurezza, non sulla correttezza o sullo stile.

Gli strumenti SAST automatizzati (Semgrep, SonarQube, CodeQL) individuano rapidamente i pattern noti, ma non rilevano i difetti nella logica di business, le vulnerabilità complesse che coinvolgono più componenti e i problemi dipendenti dal contesto. La revisione manuale individua ciò che l'automazione non rileva. Sono necessarie entrambe.

Inizi la revisione di sicurezza mappando tutti i punti di ingresso: endpoint HTTP, gestori delle code di messaggi, caricamenti di file, processi pianificati, webhook e argomenti CLI. Ogni punto di ingresso che accetta dati esterni è un potenziale punto di injection che richiede un'analisi attenta.

Tracci i dati controllati dall'utente dal punto di ingresso fino al loro utilizzo finale nell'applicazione. Raggiungono una query al database? Un comando shell? Un template HTML? Una chiamata API? Segua il flusso dei dati e verifichi ogni trasformazione e passaggio di sanificazione.

Le decisioni di sicurezza vengono prese ai confini di fiducia, dove i dati passano da un contesto meno affidabile (una richiesta HTTP) a uno più affidabile (un database, il sistema operativo). Ogni attraversamento di un confine di fiducia deve convalidare, sanificare o autorizzare i dati.

Contrassegni l'uso di: eval(), exec(), system(), shell_exec(), innerHTML, dangerouslySetInnerHTML, deserialize(), pickle.loads(), Runtime.exec(), ProcessBuilder, parser XML per i quali l'espansione delle entità non è disabilitata e primitive crittografiche usate direttamente anziché API di alto livello.

Verifichi: ogni endpoint sensibile è protetto dall'autenticazione? L'autorizzazione viene verificata lato server per ogni azione? Un utente può accedere ai dati di un altro utente modificando un parametro ID (IDOR)? Le operazioni sensibili sono protette da CSRF?

Individui i blocchi catch che ignorano silenziosamente le eccezioni. Verifichi che i messaggi di errore mostrati agli utenti non rivelino percorsi interni, stack trace o la struttura del database. Verifichi che le eccezioni di sicurezza (AuthenticationException) vengano registrate e non ignorate silenziosamente.

Contrassegni: MD5 o SHA-1 per l'hashing delle password (usi bcrypt/Argon2), chiavi simmetriche o IV codificati nel codice, cifratura in modalità ECB (usi GCM o CBC con HMAC), implementazioni crittografiche personalizzate e generatori di numeri casuali non crittograficamente sicuri.

Esamini package.json/pom.xml alla ricerca di dipendenze obsolete. Verifichi nella configurazione dell'applicazione se la modalità di debug è abilitata in produzione, se sono presenti pagine di errore dettagliate, credenziali di amministratore nei file di configurazione e intestazioni di sicurezza mancanti (HSTS, CSP, X-Frame-Options).

Le regole di Semgrep confrontano i pattern sintattici tenendo conto della semantica. Scriva regole personalizzate per i pattern specifici della base di codice. CodeQL tratta il codice come dati: scriva query sull'AST per individuare flussi di dati dalle sorgenti ai sink tra file e chiamate di funzione.

Che cos'è una vulnerabilità IDOR e dove la cercherebbe durante una revisione del codice?

Una revisione efficace della sicurezza del codice combina la mappatura dei punti di ingresso, il tracciamento dei flussi di dati, l'analisi dei confini di fiducia, il rilevamento delle API pericolose e gli strumenti SAST automatizzati. Individua problemi di sicurezza che la revisione funzionale non rileva, in particolare difetti nella logica di business e sottili lacune nell'autorizzazione.