Vai al contenuto
Home » Le cose che uno sviluppatore deve sapere su penetration test e code review

Le cose che uno sviluppatore deve sapere su penetration test e code review

Ormai i serial come CSI, NCIS o quelli nostrani sul RIS, sono entrati
nell’immaginario collettivo. Fin dai tempi del tenente Colombo, sappiamo che la
scena di un crimine può essere facilmente inquinata se qualcosa viene toccato o
modificato. Una volta inquinata, la scena del crimine non è più in grado di
permetterci di risalire alla dinamica degli accadimenti, non facilmente almeno.

Ecco, nella sicurezza applicativa lo stesso si può dire con penetration test e
code review. Se cambiano alcune cose durante i test, è come se qualcuno avesse
inquinato la scena di un crimine, i test perdono di validità e così i
risultati.

Code review

Vediamo l’esempio più semplice e che forse è più facilmente comprensibile.
L’analisi del codice, per trovare issue di security, fotografa lo stato di
un’applicazione in un certo istante, quello del checkout dal repository che si
sta analizzando.

Se cambia il codice, perché vengono fatti dei commit, è chiaro come i test
possano perdere di efficacia. Quello che è stato testato, non è più quello nel
repository del codice, quindi i risultati non sono più attendibili.

Gli sviluppatori poi, di fronte alle sacrosante lamentele, ti guardano con
gli occhi alla Bambi dicendo “ah ma dovevi testare anche questa?”.

Quando lo spiego nel quotidiano, mi sento dare, come giustificazione un po’
scocciata, che in fondo è cambiato poco e in altri punti rispetto ai risultati
che ho presentato dopo l’analisi. Quello che non riesco a far capire, o forse
che il team di sviluppo non vuole capire, è che il codice è tutto collegato ed
una modifica in un punto può avere effetti ed impatti anche in altre porzioni
dell’applicazione.

Morale della favola. Durante una code review, il codice deve rimanere fermo. Se
il codice cambia, i test devono essere eseguiti di nuovo.

Penetration test applicativo

Qui ci si sbizzarisce. L’ambiente di test spesso non esiste e quando esiste
spesso non è allineato con quello di produzione. Catene diverse. I dati non
passano attraverso WAF con la giusta configurazione; non ci sono firewall o
quelli che ci sono sono virtuali invece che fisici; i web server non sono gli
stessi e ci sono modifiche ad hoc alla configurazione per gestire i test.

Fare test in questi scenari è inutile, assolutamente inutile.

Da una parte appare chiaro come non si possano sporcare i dati della produzione
con test di security, dall’altra parte ci si chiede se e come sono stati fatti
i più banali test funzionali visto che lo scenario è differente da quanto in
esercizio.

Qui la sensibilità di chi fa sviluppo è ai minimi storici. Ogni tanto salta
fuori un particolare controllo fatto solo in un ambiente o qualche pagina di
amministrazione che non esiste in ambiente di test e viceversa. Gli
sviluppatori poi, di fronte alle sacrosante lamentele, ti guardano con gli
occhi alla Bambi dicendo “ah ma dovevi testare anche questa?”.

La risposta che un team di sicurezza applicativa deve dare, deve essere il
più vicino al realtime possibile.

Il penetration test applicativo ha lo scopo di simulare l’attività di un
attaccante, umano o software, che trovato un link, lo segue e prova differenti
tecniche di iniezione. Eventuali percorsi non referenziati, non sono al sicuro:
semplicemente l’attaccante dovrà lanciare qualche strumento per il bruteforce
delle directory. Il problema è che lo sviluppatore o il sistemista medio,
sottovaluta di molto quelle che possono essere le armi in dotazione di un
attaccante.

Morale della favola. Un penetration test applicativo va fatto in uno scenario
esattamente uguale a quello presente in produzione. Dovrebbe essere la
norma per gli UAT, figuriamoci per i test di security.

Non siamo però sempre dalla parte della ragione

La security però non è sempre dalla parte della ragione, anzi da anni sta dando
una risposta a mio avviso sbagliata, ai problemi dei team di sviluppo e
operation. Se è vero che per la code review serve il codice fermo, è anche vero
che spesso, visti i time to market sempre più pressanti, questa condizione non
accade MAI e solitamente il tempo richiesto per una code review, un paio di
settimane, semplicemente non è accettabile.

Per i penetration test, il discorso è già diverso. Si può lavorare durante gli
UAT, anche se meglio lavorare in produzione e fornire un output il prima
possibile. Il test dovrebbe poi essere fatto sia con le difese (firewall
tradizionali ed applicativi) alzate, che senza alcuna barriera. Questo permette
al team di test di capire se ci sono della vulnerabilità reali, per le quali
viene fatto virtual patching o se veramente il codice è robusto da un punto
di vista di security.

La risposta che un team di sicurezza applicativa deve dare, deve essere il più
vicino al realtime possibile. Un paio di giorni per i test ed un paio per i
risultati, non di più. Questo risultato si può raggiungere solo applicando la
costruzione di una pipeline di security, che spalma i controlli nel tempo,
lungo tutta la filiera di sviluppo.

Approcciare il test come fatto fino ad ora, non porta benefici al cliente. Poi
chiaramente, per il portale che verrà modificato un paio di volte l’anno, ha
senso fare un test alla fine dello sviluppo, ma pensiamo ad un applicazione
mobile o ad un portale che ha un paio di rilasci a settimana… in questo caso,
come vogliamo comportarci? Se non cambiamo il nostro approccio, non potremo mai
dare una risposta a questa tipologia di clientela più dinamica, quindi avremo
sempre fallito il nostro obiettivo: avere un web più sicuro.

Enjoy it!

Tag:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.