Avevo un lavoro in cui un manager diceva che gli piaceva chiamare i server dopo i posti perché se fossero stati nominati in modo descrittivo, ad es. "server di database delle password" diventano obiettivi ovvi. Ho generalizzato questo concetto e quando scrivo codice evito di nominare variabili come "password". Questo aiuta la sicurezza o confonde le persone con cui dovrei lavorare?
Dare nomi non ovvi a cose è simile a sicurezza attraverso l'oscurità che di solito è disapprovato da queste parti. Il problema con quel tipo di sicurezza non è che non funzioni; anzi, ha un certo valore, che è stato dimostrato molte volte attraverso la Storia (es. ecco perché un serbatoio si chiama "tank" e non "chariot blindato"). Ma non puoi quantificare la sicurezza attraverso l'oscurità. Non puoi sapere "quanto" sicurezza ti compra; e, in particolare, non puoi sapere se funziona (e anche se spesso funziona bene, spesso fallisce in modo spettacolare).
Pertanto, quando si pensa alla gestione del rischio , il valore dei nomi non standard deve essere considerato basso. Questo non sarebbe un problema se potesse essere fatto "gratuitamente"; ma i nomi non standard hanno un costo nascosto enorme: se confondono gli attaccanti, è probabile che confondano anche gli amministratori di sistema. Sifonerà tempo e risorse per pensare, e aumenterà la latenza della reazione in caso di problemi.
In realtà, nella sicurezza IT e nell'IT in generale, i nomi descrittivi sono un must.
Questo sarebbe un ottimo esempio di Sicurezza attraverso l'oscurità . Sebbene questo fornisca un qualche valore di sicurezza, il guadagno è generalmente molto minimo e dovrebbe non essere invocato come difesa finale.
Come per qualsiasi misura di sicurezza, ecco come bilanciare sicurezza e usabilità qui è quello che la vostra organizzazione deve decidere. Se riesci a trovare una convenzione di denominazione conveniente che sarebbe ragionevolmente oscura per gli estranei, ma facile da imparare per te e il tuo team, potrebbe essere una considerazione interessante. Se si verificano costantemente problemi significativi perché le persone non riescono a ricordare o non riescono a trovare facilmente un elenco di nomi di server o variabili essenziali, potrebbe essere il momento di ri-considerare se questa soluzione particolare è giusta per te.
Se stai scrivendo un pezzo di codice sensibile alla sicurezza, ti conviene usare nomi che spieghino chiaramente quali sono tutte le informazioni sensibili.
Se una parte di testo è una password, ma la chiami string1 , quindi il prossimo programmatore che entra dopo aver scritto codice che non tratti la variabile con cura adeguata.
Ad esempio, lui o lei potrebbe aggiungere un'istruzione di debug che sputa il contenuto di string1 in un log, rendendo le password disponibili a qualcuno che può attivare il debug e accedere ai log.
Ad ogni modo, il codice sorgente in realtà non contiene password, solo variabili chiamate password, a meno che non sia orribilmente insicuro. Nessuno acquisirà alcuna password cercando le variabili chiamate password nel codice sorgente.
C'è una grande differenza tra la selezione dei nomi per i server che non identificano la loro funzionalità, forse rendendoli obiettivi più ovvi per gli hacker e usando nomi oscuri nel codice del programma.
I nomi che usi per variabili nel tuo codice non finiscono nel binario / eseguibile finale del programma. Questi nomi esistono solo nel codice sorgente. Se qualcuno ha accesso al codice sorgente, i nomi oscuri forniranno poca protezione. Tuttavia, per quei poveri manutentori che ti seguono sarà davvero scomodo. In effetti, a lungo termine, potrebbe persino ridurre la sicurezza del programma poiché i manutentori successivi hanno maggiori probabilità di fraintendere o interpretare erroneamente a cosa serve la variabile.
Quando scrivi il codice, il primo e più importante obiettivo è la correttezza. Dopo ciò, è la comunicazione dell'algoritmo e l'intento del codice. L'uso di nomi variabili che non rispecchiano in modo accurato lo scopo della variabile ne ridurrà il valore e renderà più difficile la manutenzione. È l'algoritmo che determinerà quanto è sicura la tua soluzione, non i nomi che usi per le variabili.
Il guadagno principale che puoi ottenere dalla denominazione dei server sta aumentando la necessità di indovinare e semplifica l'implementazione di qualcosa come un honeypot per cercare di identificare gli aggressori. È ancora sicurezza attraverso l'oscurità e non fornisce alcuna sicurezza a sé stante.
Per quanto riguarda l'uso dell'offuscamento nel codice di programmazione, è importante considerare che, a seconda della lingua, questo potrebbe già essere fatto per te. Molti linguaggi compilati scartano i nomi dei metodi e delle variabili nelle versioni e gli strumenti di offuscamento del codice sono disponibili per molte lingue che non sono stati compilati o tengono traccia dei nomi delle variabili (come .Net).
Il problema principale con l'offuscamento dei nomi nel codice è che diminuisce la sicurezza riducendo la leggibilità. Il codice complesso e non gestibile è quasi sempre meno sicuro poiché la complessità aggiunta aumenta gli errori e gli errori possono portare a falle nella sicurezza. La soluzione migliore è scrivere un codice molto semplice e molto manutenibile quando è fondamentale per la sicurezza e quindi, se lo si desidera, confonderlo con un pacchetto commerciale per rendere più difficile per un utente malintenzionato analizzare cosa devono fare per tentare di attaccarlo.
Leggi altre domande sui tag source-code server