Ho una base di codice che ha bisogno di una revisione del codice per valutarla per backdoor.
Il codice è troppo grande per poterlo rivedere, come consiglieresti di affrontare il problema.
È un'applicazione web java con un database Oracle, il codice è personalizzato da un prodotto che è estremamente grande.
Le personalizzazioni coprono quasi tutto il codice base, ma posso identificare automaticamente il codice personalizzato.
Vorrei iniziare con una panoramica strutturale: dal punto di vista del design, le parti separate del codice sono ben definite? ad esempio, hai codice di convalida, funzioni di input e output ecc. che vengono utilizzate per questi scopi in tutto il codebase o ogni funzione è individuale? Avete un codice che è funzionalmente sicuro (spesso certe costruzioni di stile non influiscono sulla sicurezza del flusso di dati)
Se si dispone di un wrapper di sicurezza che esegue l'autenticazione per ogni funzione, è possibile eseguire una revisione di tali funzioni e controllare l'utilizzo della funzione wrapper, ad esempio.
Se è un codebase molto grande, allora vorrai eseguire uno strumento come Fortify (o altri che @AviD sarà in grado di nominare :-) per fare un primo passaggio al problema, ma tutti gli strumenti soffrono di una mancanza di intelligenza del contesto. Identificano in base alle firme tipiche, quindi otterrete falsi posisivi (e possibilmente falsi negativi - ecco perché avere una buona panoramica può aiutare a identificare i rischi che uno strumento non individuerà)
L'idea è che lo strumento restringa le possibili aree di rischio e identifica la grande maggioranza dei problemi, poiché gli strumenti sono relativamente economici, quindi un umano convalida e aggiunge all'output dello strumento, inserendolo nel contesto dell'ambiente applicativo.
A rischio di sembrare eccessivamente commerciale, consiglierei di utilizzare i servizi di un consulente esperto in sicurezza che non solo conosce lo strumento di revisione del codice e conosce perfettamente Java + Oracle, ma anche qualcuno esperto in architettura basata sul rischio aziendale e di sicurezza.
La linea di fondo: sei fregato. Se sei preoccupato che uno degli sviluppatori abbia nascosto deliberatamente una backdoor in quel codebase, non hai alcuna speranza realistica di dire se sia presente una backdoor. La vita fa schifo.
Commento: alcuni utenti suggeriscono che è possibile verificare la presenza di una backdoor rivedendo il codice o utilizzando strumenti di analisi statici o somesuch. Non ci credo. Stanno ingannando se stessi se pensano che questo sia in grado di rilevare una backdoor deliberatamente nascosta. A mio avviso, queste risposte sono eccessivamente ottimistiche e potrebbero darti un falso senso di sicurezza. (So che mi renderò impopolare dicendo questo e dissing altri commentatori, ma sento la responsabilità di darti il mio onesto, franco consiglio.)
Consigli e attenuazioni: Per quanto riguarda ciò che dovresti fare, penso che tu abbia bisogno di dirci di più sulla funzione di quel software, su come si rapporta alla tua attività e quali sono le conseguenze se ha una backdoor. Ecco alcune attenuazioni generiche che potresti prendere in considerazione, che potrebbero o non potrebbero essere rilevanti per te, a seconda delle circostanze:
Trasferimento del rischio. Richiedere al fornitore di fornire una garanzia che il codice sia privo di backdoor, con eventuali clausole sanzionatorie finanziarie se presenti. (Si noti che, se è presente una backdoor, è probabile che le probabilità siano molto basse, quindi le penalità se ne viene trovata una devono essere proporzionalmente aumentate rispetto alla probabilità di rilevarlo.)
Isolamento. Potresti provare a isolare l'effetto di una backdoor, in modo che possa influenzare solo il funzionamento di questo software e abbia possibilità limitate di attaccare altri tuoi sistemi. Potresti eseguirlo in una macchina virtuale, disattivarlo dalla rete, ecc. Potresti potenzialmente anche farlo fuori dalla rete, per rendere più difficile per un cattivo l'attivazione della backdoor.
Monitoraggio. In alcuni casi, potrebbe essere possibile eseguire un monitoraggio esterno per rilevare attività illecite. Ad esempio, in un comune slot-machine, è possibile monitorare la quantità di denaro prelevata, l'importo pagato e, statisticamente, questi due dovrebbero avere una relazione strong; se vedi i pagamenti che superano l'importo previsto di oltre cinque deviazioni standard, quello potrebbe essere un buon motivo per preoccuparsi. Come altro esempio, in una banca, potresti essere in grado di utilizzare la contabilità a partita doppia e tenere traccia di alcune metriche aggregate, come il tasso di reclami dei consumatori e la frequenza con cui i consumatori contestano le accuse. Questi tipi di tecniche di monitoraggio sono altamente specifici per la tua attività, ma possono essere potenzialmente efficaci nel rilevare shenanigans.
Ricorda che nessuno di questi è in grado di fornire una difesa davvero buona contro backdoor deliberati, e potrebbero o meno essere applicabili in qualsiasi situazione particolare, ma se sei fortunato, potrebbero essere meglio di niente.
@Rory ha praticamente coperto come fare la recensione ...
Aggiungo che dovresti sapere cosa stai cercando, e non solo "backdoor" in generale (simile a ciò che @ VP01 ha detto nel suo commento in alto).
es. stai cercando backdoor che facciano:
Se sai cosa sono i tipi di backdoor che stai cercando, non devi concentrarti sullo stesso livello su ognuna delle milioni di righe di codice, e puoi dare la priorità.
Aggiungerò anche che ci sono alcuni strumenti automatici che possono essere scriptati in modo molto ricco, in modo tale che supporti la ricerca di quei tipi specifici di backdoor che definisci, basati sull'intelligenza umana e sul contesto, quindi lo applica in milioni di LOC ...
P.S. potresti essere interessato ad alcune di queste domande correlate:
Penso che la risposta di Rory tocchi il kernel, ma il tempismo è davvero importante qui. Per fare la revisione del codice dopo che il codice è già enorme, mal documentato, mal testato, in produzione (non so se questo è il caso qui) è già quasi "troppo tardi" per farlo bene. Anche con i migliori strumenti e analisti esterni Java / Oracle sarà più difficile capire i difetti della logica di business (intenzionalmente piantati lì). Secondo me l'analisi del codice dall'inizio è la strada da percorrere.
Esistono alcuni metodi comuni a ogni revisione di un'applicazione, indipendentemente dalla lingua utilizzata. Ecco alcuni suggerimenti:
Leggi altre domande sui tag audit code-review