I 17 ERRORI DEI PROGRAMMATORI

Dopo aver letto questo articolo riguardo i 17 errori più comuni dei programmatori in ambito di sicurezza, ho voluto fare questo articolo a riguardo commentando punto per punto. Per chi non l'avesse ancora letto, ricordo l'errore più comune dei programmatori Android.

-1- Accettare qualunque tipo di input

Una cosa molto simile a questa era già stata trattata nell'articolo Ritardare meglio che curare su Programmazione Applicata. Quando viene creato un form di inserimento dati non viene fatta attenzione alla tipologia di dati inseriti (ad esempio il controllo del NaN) lasciando una vulnerabilità verso attacchi di tipo SQL injection o comunque elaborazioni eccessive ed inutili lato server. Inserire dei controlli lato client sulla lunghezza dei dati e sul tipo potrebbe rivelarsi la soluzione migliore.

-2- Memorizzare più del necessario

In passato ho trovato più di un progetto la cui base dati era stracolma di informazioni. Avere molte informazioni, piuttosto in ambito di sicurezza informatica, significa avere molti dati sensibili alla portata dei possibili malviventi, nonchè un significativo utilizzo di risorse per gestire la mole di dati. La soluzione al problema è difficile ottenerla, in quanto il programmatore crede sempre di aver bisogno di tutti quei dati quando in realtà non è così, tuttavia l'adozione di strutture dati standardizzate e metodologie di progettazione corrette come il Paradigma UGL aiutano a raggiungere l'obiettivo.

-3- Hai sbagliato? riprova!

Come già visto in Ritardare meglio che curare accettare l'inserimento di password senza effettuare controlli può mettere a rischio il sistema. Di metodi ne esistono molti, alcuni semplici ed altri complessi, tuttavia è necessario adottare almeno qualche contromisura per evitare problemi di questo tipo. In una applicazione web consiglio sempre di tracciare, quanto possibile, l'indirizzo IP del client che effettua l'accesso oppure nelle applicazioni standalone di inserire un CAPTCHA. Stesso discorso può essere applicato al di fuori della sicurezza informatica, anche l'upload di un file, come visto in Upload di file in Java e Upload di file in dotNet, può essere rischioso se viene accettato qualunque tipo di input.

-4- La sicurezza solo in un punto

L'argomento di sicurezza informatica deve essere trattato da ogni reparto coinvolto nello sviluppo di un prodotto. Prendiamo ancora una volta l'esempio del form di login di una applicazione web, il controllo dell'input non deve essere effettuato esclusivamente dal javascript della pagina di accesso, deve infatti essere presente anche lato server. Sostanzialmente ogni reparto coinvolto nella progettazione e realizzazione software deve avere in mente di proteggere il sistema e le informazioni in esso contenute.

-5- Tutto veloce, senza ritardi

Questo ricalca perfettamente l'articolo Ritardare meglio che curare non credo ci sia da aggiungere molto.

-6- Tutto in chiaro

Di algoritmi di crittografia ne esistono molti, basta seguire una lezione di storia romana o di seconda guerra mondiale per avere già degli ottimi spunti, ne esistono anche di già fatti in librerie open source o a pagamento quindi.. perchè non usare la crittografia? Non mi sto riferendo ad aggiungere method=POST in un form HTML, mi riferisco a trasmettere informazioni in maniera criptata quanto possibile.

-7- Una sola chiave per tutte le porte

Quasi tutte le applicazioni intranet installate in una azienda possiedono un form di login unificato con l'account di dominio in modo da non far imparare agli utenti mille password per tutte le necessità. A volte però può essere necessario avere una password diversa per sistemi diversi (un po' come le varie password di alcuni servizi di web banking).

-8- Utilizzare librerie alpha/beta

L'utilizzo di librerie open source è valido, ma attenzione ad utilizzare librerie che non sono ancora state testate a dovere, potrebbero contenere bug enormi come palazzi. (Attenzione anche a quelle a pagamento il cui supporto è terminato da anni)

-9- La funzione da 1000 righe

Credo che nel 2014 la programmazione funzionale sia alla portata di tutti i programmatori present sul globo, tuttavia è sempre bene ricordare che un codice diviso in funzioni e sotto funzioni è più facile da analizzare.

-10- Il codice è mio e lo guardo solo io!

Giorni fa è morto Robin Williams, una delle sue parti recitava 

"Sono salito sulla cattedra per ricordare a me stesso che dobbiamo sempre guardare le cose da angolazioni diverse. E il mondo appare diverso da quassù. Non vi ho convinti? Venite a vedere voi stessi. Coraggio! È proprio quando credete di sapere qualcosa che dovete guardarla da un'altra prospettiva."

[L'Attimo fuggente (Dead Poets Society), 1989]

Ho voluto usare questa citazione per far capire che spesso guardando il codice da un'altra prospettiva si possono notare problemi e vulnerabilità, tanto vale farlo guardare direttamente da un collega o un amico professionista. 

-11- Non utilizzare profiler

Utilizzare strumenti di analisi del codice sorgente come i profiler aiutano il programmatore a scovare elaborazioni estremamente complesse e rischiose. Utilizzare sempre uno strumento per l'analisi del codice sorgente, ne esistono moltissimi open source gratuiti quindi non avete scuse.

-12- Tutto il potere in mano all'utente

Gli utenti non sono vostri amici, non sono laureati, non sono intelligenti e se possono vi recano torto; se tenete in mente queste caratteristiche cercherete sempre di limitare i diritti dell'utente all'interno del sistema. Questo vale anche per le utenze SQL con cui vengono eseguiti i programmi, durante un'operazione di login l'utente sql non ha necessità di avere i diritti di cancellazione del database no?

-13- Pensare che vada sempre tutto bene

Dovete pensare, anche per gioco, di essere per un momento un malintenzionato che vuole rubare i dati dai vostri sistemi. Magari potrebbe essere un ottimo gioco di società adottato dal PM per fare brain storming in fase di analisi. Mettersi nei panni di chi vuole rubare i dati permette di implementare meccanismi di difesa più efficienti. Questo può essere applicato anche al di fuori dell'argomento riguardo la sicurezza informatica, infatti il sistema deve prevedere l'inserimento di input non corretti da parte di un utente.

Come recitano le parole del primo assioma di Arthur Bloch (legge di Murphy):

"Se qualcosa può andare male, di certo lo farà"

[La legge di Murphy, Arthur Block 1988] 

-14- Avere troppa fiducia nell'utente finale

Uno dei primi tempi in cui Google aveva adottato il metodo di accesso sicuro via SMS, mi venne spontaneo dubitare riguardo l'inserimento del mio numero personale di cellulare per verificare la mia identità. Questo significa che a volte potrebbe essere l'utente stesso a non avere fiducia nei meccanismi di sicurezza del sistema ed evitare volontariamente di inserire determinati dati.

-15- Re-Inventare la ruota

Ancor prima di mettersi davanti ad un compilatore deve essere buona norma controllare online l'esistenza della soluzione al proprio problema, in questo modo non si trova solo la soluzione ma anche molte persone che hanno affrontato prima di te i vari problemi facendoci risparmiare tempo e denaro.

-16- Non essere aggiornati

L'educazione di se stessi e la formazione sono aspetti fondamentali della crescita di un programmatore/progettista. Seguire corsi online o master universitari, leggere libri specializzati o semplicemente Programmazione Applicata sono tutte cose che possono servire a risolvere ed evitare problemi ed accrescere la propria esperienza. Rimanere ignoranti non serve nè a voi stessi nè a chi vi paga.

-17-

E il 17° errore? beh questo ditemelo voi sono curioso di sapere qual'è secondo voi un errore comune che non sia elencato qui sopra.