7 comuni errori di configurazione della sicurezza delle app

28/03/2024

Tutti commettono errori sul lavoro. È naturale dell’essere umano. Le persone si distraggono e dimenticano le cose. La maggior parte delle volte, non è un grosso problema. Per uno staff del Pentagono, però, una semplice svista ha portato a una fuga di dati che ha esposto le email militari degli Stati Uniti all’intero internet. Questa configurazione errata della sicurezza dell’app ha lasciato un server del Dipartimento della Difesa senza protezione password. Chiunque conoscesse l’indirizzo IP del server poteva accedere ai dati sensibili ma non classificati, che includevano email riguardanti operazioni speciali militari.

Per essere giusti nei confronti dello sviluppatore, il suo errore è stato solo uno in una serie di omissioni che hanno portato alla fuga di dati di due settimane a febbraio di quest’anno. E, probabilmente, non è stata neanche la peggiore violazione delle email del Pentagono di quest’anno. Successivamente, hacker russi hanno sfruttato la vulnerabilità di MOVEit per accedere alle email di diversi dipendenti di alto livello del Dipartimento della Difesa.

Le configurazioni errate della sicurezza dell’app sono responsabili di molte altre costose fughe di dati, incluso il 2022 Microsoft BlueBleed data leak che ha esposto i dati di oltre 150.000 aziende in 123 paesi. Secondo l’OWASP, il 90% delle applicazioni testate includeva qualche forma di configurazione errata della sicurezza. Il CISA riporta che questo è un problema significativo in tutti i settori, anche tra le organizzazioni con un solido assetto di sicurezza.

Le 7 configurazioni errate della sicurezza delle app più comuni

Una configurazione errata della sicurezza dell’applicazione è una vulnerabilità causata dal modo in cui gli sviluppatori configurano un’applicazione o un ambiente. Non è un difetto intrinseco all’applicazione stessa. Alcuni dei tipi più comuni di configurazioni errate della sicurezza delle app includono i seguenti:

1. Configurazioni Predefinite
Con così tante applicazioni che vantano funzionalità pronte all’uso, non dovrebbe sorprendere il fatto che uno dei rischi di configurazione più significativi sia il mancato cambiamento delle impostazioni predefinite. Questo errore è una spiegazione del fatto che la password più comune, anche nel 2023, è ancora 123456.

Gli ambienti di sviluppo, in particolare prima della distribuzione, spesso hanno configurazioni di sicurezza deboli per facilitare un’iterazione veloce o un debug ampio. Per evitare falle di sicurezza, le impostazioni dovrebbero essere rafforzate prima della distribuzione come parte del processo di consolidamento dell’applicazione in fase avanzata.

2. Controllo di accesso inadeguato
L’unica cosa peggiore di avere una password insicura è non averne affatto. Come illustrano le fughe di dati del Pentagono e di Microsoft, questa è una configurazione errata abbastanza comune. Un controllo di accesso insufficiente include credenziali deboli o mancanti che potrebbero consentire l’accesso non autorizzato al sistema o all’applicazione. Le squadre DevSecOps dovrebbero incorporare protocolli robusti di gestione dei privilegi d’accesso, idealmente basati sulla fiducia zero, lungo tutto il ciclo di sviluppo. Con così tanti componenti di sistema ora basati su cloud, la sicurezza perimetrale non è più sufficiente.

3. Componenti non aggiornati
Quasi tutte le applicazioni software contengono codice open-source, il che significa che le loro debolezze e vulnerabilità sono spesso di dominio pubblico. Quasi il 60% delle violazioni dei dati degli ultimi due anni avrebbe potuto essere evitato applicando patch alle vulnerabilità conosciute. Una volta scoperte le vulnerabilità del software open-source, gli hacker possono facilmente sfruttarle. Non è raro che gli attacchi avvengano mesi o anni dopo che una patch è stata rilasciata. Questo dovrebbe essere un obiettivo scontato per le squadre di sviluppo, ma tracciare tutti i componenti open-source in grandi codebase può essere difficile, specialmente se sono nascosti nelle dipendenze. Le squadre DevSecOps possono utilizzare uno strumento automatizzato di analisi della composizione del software (SCA) per esaminare la propria codebase e individuare tutti gli incidenti di codice open-source in modo che possano essere aggiornati e patchati adeguatamente.

4. Divulgazione eccessiva durante la gestione degli errori
Gli sviluppatori naturalmente desiderano ottenere il maggior numero possibile di informazioni quando si verifica un errore per poterlo risolvere rapidamente. Tuttavia, visualizzare troppi dati sugli errori agli utenti può rivelare falle potenzialmente sfruttabili agli attori malintenzionati.

Anche i messaggi di errore che non sembrano rivelare informazioni di per sé possono farlo quando combinati con altri messaggi di errore. Ad esempio, se un utente cerca un file e riceve il messaggio di errore “File non trovato”, e poi cerca un file diverso e riceve “Accesso negato”, può logicamente dedurre che il secondo file esista sul server. Le squadre DevOps dovrebbero creare standard per la gestione degli errori che restituiscano messaggi utili ma generici agli utenti, trasmettendo al contempo informazioni diagnostiche agli ingegneri.

5. Intestazioni di sicurezza deboli o mancanti
Le intestazioni di sicurezza HTTP possono proteggere contro gli attacchi di scripting tra siti (XSS) e clickjacking. Configurare intestazioni sicure su applicazioni web è uno dei modi più semplici per rafforzare le applicazioni. Anche se ci sono molteplici intestazioni di sicurezza che gli ingegneri possono implementare, le seguenti sono le più importanti per bloccare unilateralmente intere classi di attacchi:

Intestazione Strict-Transport-Security (HSTS) per forzare l’uso di connessioni crittografate
Content-Security-Policy (CSP) per un controllo granulare sui parametri del contenuto
X-Frame-Options per impedire che le pagine vengano caricate in iframes

6. Funzionalità non necessarie
In un ambiente in cui più è meglio e si tende all’aggiunta continua di funzionalità, disabilitare alcune di esse può sembrare uno spreco. Tuttavia, lasciare attive porte, servizi, account, privilegi o pagine non utilizzati fornisce l’opportunità di iniettare codice maligno in un’applicazione. Se le funzionalità non vengono utilizzate, non c’è motivo di abilitarle. Oltre ad aumentare la superficie di attacco, rappresentano uno spreco di risorse.

7. Mancanza di segmentazione di rete
Anche se una rete non segmentata non è di per sé una vulnerabilità sfruttabile, avere una rete monolitica facilita l’escalation dei privilegi quando un hacker ottiene l’accesso. Le squadre DevOps possono implementare controlli di sicurezza robusti su una rete segmentata. Le subnet possono essere protette in base al tipo di dati e applicazioni che contengono. Con connessioni limitate tra le reti, un hacker che ottiene l’accesso a una rete attraverso una falla di sicurezza non avrà le chiavi del regno.

Le migliori pratiche per evitare configurazioni errate della sicurezza delle applicazioni 

La sicurezza delle applicazioni è un processo multilivello che le squadre devono integrare nel processo di sviluppo fin dalle fasi più precoci. È significativamente più difficile — se non impossibile — affrontare adeguatamente la sicurezza alla fine del ciclo di vita dello sviluppo del software (SDLC). Come parte di un approccio DevSecOps completo allo sviluppo, le squadre dovrebbero implementare protocolli standard per prevenire configurazioni errate della sicurezza, compresi processi automatizzati per rilevare e mitigare le vulnerabilità durante la fase di sviluppo.

Static application security testing (SAST) possono individuare configurazioni errate comuni della sicurezza delle applicazioni in modo che possano essere corrette prima della distribuzione. Gli SCA tools  (SCA) possono trovare codice open-source in modo che le organizzazioni possano installare patch e aggiornamenti non appena diventano disponibili.

Migliora la tua strategia di sicurezza con Kiuwan

Kiuwan produce una suite completa di potenti strumenti di automazione della sicurezza che permettono agli sviluppatori di essere più efficaci in tutte le fasi del ciclo di vita dello sviluppo del software (SDLC). La nostra piattaforma di sicurezza delle applicazioni end-to-end si allinea con i framework di sicurezza standard del settore e funziona con tutti i principali linguaggi di programmazione.

Ottieni una DEMO del servizio di Kiuwan

Articolo originale

 

 

PUBBLICATO DA:<br>Sara Guglielmi
PUBBLICATO DA:
Sara Guglielmi
Marketing

ARTICOLI CORRELATI

Quali sono i vantaggi di una API anti-phishing?

Quali sono i vantaggi di una API anti-phishing?

Gli esseri umani sono l’anello più debole e il phishing sfrutta l’errore umano. Gli autori di phishing inducono un senso di urgenza nei destinatari, quindi i dipendenti sono spesso costretti a compiere azioni dubbie senza pensare alle conseguenze. Il risultato è...

Come cercare malware UEFI utilizzando Velociraptor

Come cercare malware UEFI utilizzando Velociraptor

Le minacce UEFI sono storicamente limitate in numero e per lo più implementate da attori statali come persistenza furtiva. Tuttavia, la recente proliferazione di Black Lotus sul dark web, il modulo di enumerazione Trickbot (fine 2022) e Glupteba (novembre 2023) indica...