Software sicuro

Sun Aug 16 15:12:00 CEST 2020 - Thu Dec 31 15:05:00 CET 2020
“Every company is a software company”. La crescita esponenziale delle minacce informatiche, genera ricadute dirette anche in fase di sviluppo Software. Il contesto globale di generale insicurezza, assente agli arbori dell'era digitale, ha costretto lo Sviluppo a fare i conti con la sicurezza.

Software sicuro in breve

La maggioranza delle applicazioni (76%) presenta falle di sicurezza, mentre quasi una su quattro (24%) ha difetti di gravità elevata.

Le librerie open source possono essere un problema. Purtroppo il 97 % di una tipica applicazione in Java è costituito da librerie open source.

Due applicazioni su tre terzi delle applicazioni mantiene o riduce la quantità totale di falle di sicurezza osservate tra la prima e l'ultima scansione.

Mentre molti team si limitano a svolgee analisi statiche, l'uso di una scansione dinamica può rilevare difetti non identificabili attraverso la semplice analisi statica. 

Le falle più frequenti sono:

  • Perdita di informazioni
  • Iniezione CRLF
  • Problemi crittografici
  • Qualità del codice
  • Gestione delle credenziali

 

Quali sono le vulnerabilità più frequenti?

È disponibile un'ampia varietà di framework per classificare e organizzare le diversi falle dei software (es: OWASP Top 10 e SANS 25).

Uno dei framework più accurati e completi è Common Weakness Enumeration (CWE), da cui abbiamo estratto i vlaori sottorportati.

Ci limiteremo a entrare nel dettaglio delle sole vulnerabilità più rilevanti.

Problemi di crittografia
La frequenza con cui è divenuto necessario proteggere i dati con tecniche di crittografia comporta una più alta probabilità di commettere errori, quali password inadeguate, generatori di numeri pseudocasuali deboli e implementazioni di crittografia non valide, spesso a causa dell'uso di librerie crittografiche obsolete o nel tentativo di reciclare le proprie. Implementare processi crittografici in modo errato talvolta è più dannoso del non utilizzare affatto la crittografia.

Qualità del Codice
Parlare di qualità del codice è sempre tematica delicata, poiché la criticità è insita nel prodotto fin dalla fase di sviluppo, introducendo potenziali comportamenti imprevedibile o irregolarità di funzionamento.

Le vulnerabilità meno comuni
Le criticità talvoltapiù dannose sono relativamente rare. Meno del 5% delle applicazioni presenta difetti quali Gestione del buffer, Overflow del buffer, Iniezione di codice. Tali violazioni potrebbero comportare ad esempio l'esecuzione di codice in modalità remota. Molti linguaggi e framework moderni hanno capacità integrate di gestione d'intere classi di difetti e ciò aiuta nella gestione di alcune macro tipologie di vulnerabilità.

Densità

Densità e frequenza delle vulnerabilità.

Facciamo qualche esempio per comprendere la natura del problema.

Le vulnerabilità legate alla crittografia sono fra i più frequenti come abbiamo visto con una presenza media di 3 errori ongi MB di codice. In fase di sviluppo, si tende a implementare la crittografia in parti specifiche dell'applicazione relative alla gestione di dati PII o rilevanti per l'organizzazione, quali ad esempio dati finanziari, tecnologici, know how. Ciò comporta una densità media inferiore poichè solo alcune sezioni dell'applicazione sono crittografate.

I problemi relativi all'uso di codice standard sono nel complesso piuttosto rari, come evidenziato dal fatto che compaiono nella parte più a destra del grafico. Quando peròci sono lo fanno con una altissima densità (oltre 30 difetti per 1mb). In fase di sviluppo, si tende ad aderire agli standard di codifica e eventuali difetti tendono poi a permanere e essere repplicati all'interno del codice.

I difetti di Cross-Site Scripting e di Gestione delle credenziali compaiona in quasi uno sviluppo su due. Pur avendo in tasso di frequenza similare, i problemi di Cross-Site Scripting si presentano con una densità maggiore rispetto alla gestione delle credenziali. Infatti i difetti di gestione delle credenziali sono un problema realtivo solo alle porzioni di codice relative all'autenticazione e all'autorizzazione.

Dal'altro canto risolvere un problema di Cross-Site Scripting è generalmente più veloce e facile rispetto risolvere una falla nella gestione delle credenziali.

Frequenza, densità e facilità di risoluzione dunque non hanno una correlazione diretta, e spesso in fase di sviluppo non si adottano controavvertenze in proposito, ad esempio prestando maggiore attenzione per le vulnerabilità con un grado di diffcoltà di manutenzione maggiore.

La SQL injection è tra i 10 difetti più frequenti riscontrati. Anche il tasso di densità è piuttosto elevato, suggerendo l'uso diffuso all'interno delle applicazioni di questo tipo di vulnerabilità. Fortunatamente i linguaggi moderni supportano la parametrizzazione delle query di database, e quindi correggere i difetti di SQL injection è di solito un'attività semplice.

La nostra Filosofia
IMteam Group
Cosa facciamo
Il metodo TeamQUALITY