Diventa Autore per CoreTech | Scopri di più





Pratiche di codifica sicura – I tre principi chiave

30/03/20 CoreTech Blog

Tutte le vulnerabilità di sicurezza sono il risultato di un errore umano. Tutti i problemi di sicurezza delle applicazioni web vengono introdotti dagli sviluppatori. Pertanto, l'approccio migliore per la creazione di software sicuro è quello di fare tutto ciò che è possibile per evitare di introdurre tali errori in primo luogo, invece di correggerli.

È possibile trovare diverse guide dettagliate su come creare codice sicuro durante lo sviluppo dell'applicazione, ad esempio quella fornita da Open Web Application Security Project (OWASP). Si concentrano su dettagli quali la convalida dell'input, la codifica dell'output, il controllo degli accessi, la sicurezza delle comunicazioni, la protezione dei dati, le procedure di crittografia e così via. Invece, vorremmo che tu esaminassi questo problema di sicurezza software da un punto di vista strategico.

Principio 1: Diffondere consapevolezza ed educare

Nella maggior parte dei casi, gli sviluppatori introducono rischi per la sicurezza nel codice sorgente semplicemente perché non sono consapevoli di tali rischi. Mentre le università spesso si concentrano sull'insegnamento di tali dettagli come la verifica formale, molti di loro non offrono corsi dedicati sulla sicurezza. Questo è particolarmente vero per gli sviluppatori più anziani che hanno seguito tali corsi diversi anni fa, quando ancora non c'era alcuna pubblicità sulla sicurezza.

Le università insegnano anche un numero limitato di linguaggi di programmazione quindi nella maggior parte dei casi che gli sviluppatori sono autodidatti, e alcuni problemi di sicurezza sono molto specifici del linguaggio di programmazione. Ad esempio, non troverai un rischio di overflow del buffer in Java o in C #. Anche se il corso insegna una lingua, raramente si concentra sulla codifica sicura in quella lingua.

Per assicurarsi che i team di sviluppo software non commettano errori a causa della mancanza di consapevolezza, comprensione o lacune nell'istruzione, è necessario affrontare il problema in modo strategico:

  • I responsabili dello sviluppo non devono solo essere consapevoli dei rischi per la sicurezza, ma devono essere la forza trainante della sicurezza. Uno sviluppatore senza consapevolezza della sicurezza può essere istruito, ma un responsabile dello sviluppo che non si rende conto dell'importanza della sicurezza non diventerà mai il leader della sicurezza.
  • Non fare supposizioni sulla conoscenza degli sviluppatori. Convalidalo prima e se non è sufficiente, fornisci sessioni di formazione interne o esterne dedicate esclusivamente agli standard di codifica sicuri. Non è l'idea migliore richiedere assolutamente conoscenze di sicurezza dai nuovi assunti perché questo limiterà notevolmente le tue capacità di reclutamento e gli sviluppatori possono facilmente imparare mentre progrediscono.
  • Rendersi conto che non importa quanto bene gli sviluppatori capiscono la sicurezza, nuove tecniche e attacchi appaiono molto spesso a causa della velocità con cui la tecnologia sta progredendo. Alcune di queste tecniche richiedono conoscenze di sicurezza molto specifiche che possono essere previste solo da qualcuno con una posizione di sicurezza a tempo pieno. Aspettati che i tuoi sviluppatori commettano errori e non punirli per questo.
  • Non tenere separati i team di sviluppo dai team di sicurezza. I due dovrebbero lavorare a stretto contatto. Gli sviluppatori possono imparare molto dai professionisti della sicurezza.
  • Non dare per scontato che la natura del software riduca in alcun modo i requisiti di sicurezza. Ad esempio, anche se l'applicazione Web non è accessibile pubblicamente, ma solo ai clienti autenticati, deve essere sicura come una pubblica. In generale, non cercare scuse.

Principio 2: Introdurre più livelli di verifica

Anche gli sviluppatori più consapevoli e meglio istruiti continuano a commettere errori, quindi semplicemente fidarsi di loro per scrivere codice sicuro non è sufficiente. Hai bisogno di strumenti che li aiutino a realizzare i loro errori e correggerli.

In una situazione ideale, il software deve essere testato utilizzando i seguenti strumenti e metodi:

  1. Uno strumento di analisi del codice integrato nell'ambiente di sviluppo. Tale strumento previene immediatamente gli errori di base mentre lo sviluppatore digita il codice.
  2. Una soluzione SAST (analisi statica) che funziona come parte della pipeline CI/CD. Tale soluzione analizza il codice sorgente prima che venga compilato e indica potenziali vulnerabilità del software. Sfortunatamente, SAST ha un sacco di svantaggi, tra cui un alto livello di falsi positivi.
  3. Una soluzione DAST (analisi dinamica) che funziona come parte della pipeline CI/CD. Tale soluzione analizza l'applicazione in fase di esecuzione (senza accesso al codice sorgente) e individua le vulnerabilità di sicurezza reali. Nel caso di tale software, le prestazioni sono molto importanti (le scansioni sono molto intensive)  così come la certezza che gli errori segnalati sono reali (proof-of-exploit).
  4. Ulteriori test di penetrazione manuale per gli errori che non possono essere individuati automaticamente, ad esempio gli errori della logica di business. Tuttavia, questo richiede personale di sicurezza specializzato e richiede molto tempo, quindi viene spesso eseguita solo nelle ultime fasi del ciclo di vita dello sviluppo software (SDLC).

Tuttavia, i test di sicurezza richiede molto tempo e risorse. Pertanto, è spesso necessario un compromesso tra il tempo e lo sforzo necessari per eseguire i test e la qualità dei risultati. Se è necessario un compromesso di questo tipo, la scelta di uno scanner DAST veloce che fornisce proof-of-exploit è la scelta migliore.

Principio 3: Test quanto prima possibile per promuovere la responsabilità

Per ottenere la massima qualità del codice non è sufficiente avere requisiti di codifica sicuri e linee guida di codifica sicure in atto insieme a un'infrastruttura di test. I team non  devono solo sentirsi obbligati a seguire i principi di codifica sicura durante il processo di sviluppo e farlo perché il loro codice verrà testato, ma devono anche sentire che la scrittura di codice sicuro è nel loro interesse. La codifica sicura non ha solo bisogno di regole e applicazione, ha bisogno dell'atteggiamento giusto.

Un approccio shift-left, come quello descritto in precedenza, presenta molti vantaggi, uno dei quali è che gli sviluppatori si rendono conto di essere parte integrante del panorama della sicurezza. Si sentono responsabili per la sicurezza del codice e si rendono conto che se commettono un errore, dovranno ripararlo immediatamente e non contare su qualcun altro che lo farà in seguito.

Naturalmente, è possibile testare l'applicazione per le vulnerabilità di sicurezza appena prima che entri in produzione. Tuttavia, ti costerà molto di più di quanto sarebbe ti spostassi a sinistra. Il software dovrà attraversare nuovamente tutte le fasi, che coinvolge altre risorse, non solo gli sviluppatori. Lo sviluppatore non ricorderà il codice su cui hanno lavorato o la correzione potrebbe essere assegnato a uno sviluppatore diverso da quello originale e, di conseguenza, lo sviluppatore avrà bisogno di più tempo per trovare e rimuovere la vulnerabilità. Di conseguenza, i test tardivi possono ritardare il rilascio anche di diverse settimane.

Non solo politiche di sicurezza

In conclusione, vorremmo che vi rendeste conto che i criteri di sicurezza, sebbene necessari, non sono sufficienti se vengono percepiti come una limitazione, non un miglioramento. La sicurezza inizia con l'atteggiamento giusto durante la creazione di applicazioni. E anche i migliori strumenti utilizzati per mantenere la sicurezza devono essere utilizzati nel modo corretto nel processo in modo che siano percepiti come utili, non come un onere.


Articoli su Acunetix e Hacking

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!