Due cose mi accomunano allo sviluppatore Java. La prima è l’amore per il caffè. I Javisti amano così tanto la sacra bevanda dal chicco marrone, da avergli dedicato anche il magic type dei file .class¹.

La seconda cosa, che in realtà interessa solo gli sviluppatori che leggono regolarmente Codice Insicuro, è lo smarrimento di fronte alla frase “dovete usare una libreria di safe coding” che chissà quante volte il solerte penetration tester, che non ha mai toccato una linea di codice in vita sua, avrà affermato di fronte ad un Cross Site scripting.

Certo, c’è il progetto Owasp ESAPI. Già. A mio avviso uno grosso rimpianto che deve avere il progetto Owasp nella sua interezza. Noto analogie con il non troppo compianto dal mondo, progetto Stand by WordPress. Quando si chiede a qualcuno di security di sviluppare del codice, opensource per di più, la maggior parte si da alla macchia.

Perché? Semplice, è difficile, porta via tempo e non da troppe glorie.

Meglio avventurarsi in qualcosa di sicuro, come fare un documento, organizzare delle call. Sporcarsi le mani con del codice, porta con sé il rischio, di creare qualcosa che non funziona, qualcosa che ha dei bug. E poi come lo spieghi quando vai a banfare delle tue fantomatiche competenze?

Il progetto Owasp ESAPI ha tre grandi difetti a mio avviso.

Il primo, ne abbiamo parlato poco sopra, è che non ha creato traction. Il codice è fermo, le issue aperte tantissime e nessuno ci sta lavorando attivamente.

Il secondo, figlio del primo, è la mancanza di documentazione e di test unit. Tutti odiamo scrivere documenti ma, se vogliamo attirare qualcuno a lavorare sopra il nostro codice, soprattutto quando diventa grosso come ESAPI, deve essere pieno di documentazione, di esempi e di unit test che facciano capire al newbie come orientarsi.

Il terzo è logistico. Porta dietro con se troppe dipendenze. Se un team vuole creare un’API leggera, che stia in un WAR contenuto, non può farlo perché appena installa Owasp ESAPI, questo si porta dietro il mondo intero.

Buone intenzioni, pessimo design

Una premessa, Owasp ESAPI implementa un concetto che è sacrosanto. La comunità #appsec, deve fornire degli strumenti “chiavi in mano” agli sviluppatori per scrivere codice sicuro. No WAY

Secondo me bisogna partire dalle radici. Creare qualcosa che rispecchi il principio del KISS², che sia pieno di documentazione e di esempi. Creare qualcosa coinvolgendo gli utenti finali; non deve essere qualcosa che piomba dall’alto come una sacra verità, deve essere qualcosa che ha negli sviluppatori gli early adopters.

Una libreria di controlli di security deve piacere agli sviluppatori. Deve essere costruita per rispondere alle loro esigenze.

Una libreria di controlli di security deve essere opensource, inutile forse ribadirlo. Deve essere facilmente estendibile, con la possibilità di creare regole custom. Deve essere viva, avere tanti commit e release frequenti.

Qualche alternativa

Usate Owasp ESAPI. No, non sto scherzando. Owasp ESAPI rimane un bel pezzo di codice e resta la scelta numero 1 se per voi il numero di dipendenze o un progetto un po’ poco attivo non sono dei problemi. L’elevato numero di issue aperte, 145 mentre vi sto scrivendo, rende però ESAPI più una soluzione amarcord che una scelta ponderata.

Prima alternativa: Owasp Java Encoder. Libreria senza dipendenze con lo scopo di risolvere il problema del Cross Site Scripting, attraverso l’output encoding.

Seconda alternativa: Owasp Java Validator. Questa libreria si basa sul codice di validazione presente in ESAPI. Quindi possiamo dire che è un pezzo di ESAPI estratto per fare validazione dell’input.

Terza alternativa: Coverity Security Library. Cambiamo totalmente parrocchia, Coverity è un vendor di soluzioni di analisi statica del codice e questa è la sua libreria di controlli custom. Può essere un valido player.

Off by one

Fino a quando gli sviluppatori e #appsec guys si guarderanno come se gli uni fossero di Venere e gli altri di Marte, non andremo proprio da nessuna parte. O meglio, continueremo ad farcire il mercato di fuffa senza risolvere il problema reale.

Dobbiamo da una parte fornire strategie per scrivere codice sicuro, ma dall’altra implementare queste strategie in controlli fruibili dagli sviluppatori. Sì, signori miei, dobbiamo scendere dalla torre d’avorio e sporcarci le mani col codice.

Non possiamo limitarci a suggerire di fare encoding o di fare input filtering. Dobbiamo far vedere alla gente come fare. Se fossero stati già in grado, non avremmo trovato la vulnerabilità.

Dobbiamo trovare le risposte giuste, fornire quindi controlli contro:

• XSS, CSRF e SQL Injection
• Generazione di token, numeri pseudocasuali
• Attacchi contro il meccanismo di autenticazione
• Attacchi contro il meccanismo di password reset

Dobbiamo insomma fornire alle persone, un framework di controlli che loro possano inserire nella loro applicazione web ed integrarsi in maniera trasparente.

Dobbiamo fare tutto questo ORA, altrimenti perderemo, noi persone dell’#appsec, l’ennesimo treno.

Enjoy it.