Gestione dei 10 rischi principali di OWASP

Tutti gli accessi sono autorizzati dal nostro sistema di backend sulla base dei dati necessari, tra cui l'identità del chiamante, l'endpoint chiamato e i parametri della richiesta, per evitare l'escalation verticale e orizzontale dei privilegi. Le soluzioni di controllo degli accessi vengono riutilizzate ove possibile. Le chiamate API relative all'autenticazione sono limitate per ridurre il rischio di DoS e di raccolta automatica dei dati.

Qualsiasi connessione tra i client web o i dispositivi recenti e i nostri server supporta sempre TLS. Questo include le connessioni dai browser dei client ai nostri server web, ma anche le connessioni dai dispositivi ai nostri servizi. I protocolli in chiaro non vengono utilizzati per la comunicazione tra dispositivi che trasmettono dati sensibili, a meno che non si tratti di un requisito specifico del cliente per la comunicazione tra dispositivi.

Gli algoritmi crittografici e la forza delle chiavi vengono rivisti regolarmente e aggiornati se necessario.

I dati a riposo nei nostri database SQL sono archiviati su volumi criptati.

Come prima linea di difesa contro le vulnerabilità di tipo injection, le nostre applicazioni web implementano la convalida dell'input. L'input dell'utente viene convalidato per tipo e formato, ove possibile.

I framework moderni forniscono anche una codifica appropriata per prevenire le iniezioni durante la creazione di alcuni oggetti, compresi i documenti XML, riducendo così il rischio di tali vulnerabilità.

Il rischio di SQL injection è ulteriormente ridotto in modo significativo dall'uso corretto di un ORM.

Anche il rischio di Iniezione di comandi del sistema operativo è notevolmente ridotto dallo stack tecnologico sottostante basato su Java, in cui i comandi del sistema operativo non vengono mai eseguiti dal codice.

Per quanto riguarda gli XSS, esaminiamo manualmente il nostro codice e gli ambienti di test per verificare la presenza di cross-site scripting. Alcune tecnologie e framework che utilizziamo aiutano a prevenire gli XSS applicando una codifica appropriata per impostazione predefinita.

I nostri Coding Security Standards interni e i nostri Secure Design Principles servono come elenco di requisiti di sicurezza e forniscono un elenco di regole che tutto il codice e l'architettura devono seguire. Quando prendiamo decisioni su potenziali miglioramenti, consideriamo fonti quali BSIMM e SAMM. Il nostro Consiglio per la sicurezza fornisce la governance e la supervisione della progettazione della sicurezza.

Miriamo a implementare il principio del minimo privilegio su tutti i livelli del nostro stack tecnologico. Anche la superficie di attacco viene ridotta installando solo i componenti necessari. La configurazione del server è gestita da soluzioni automatizzate per garantire la conformità alle politiche interne. Anche le configurazioni a livello di applicazione sono gestite automaticamente e controllate tramite la revisione del codice di sicurezza e l'analisi statica.

Per l'elaborazione di XML, l'elaborazione DTD in linea viene disabilitata ove possibile, oppure vengono applicate le opportune mitigazioni ove necessario.

Esaminiamo i componenti di terze parti e le loro vulnerabilità. I componenti con vulnerabilità vengono valutati e, se la vulnerabilità riguarda i nostri servizi, viene programmato un aggiornamento o una correzione in base al rischio. Nel caso di componenti open source, ciò è supportato anche dalle notifiche di GitHub relative ai componenti vulnerabili. Inoltre, eseguiamo regolarmente una scansione della rete per individuare i servizi vulnerabili nei nostri ambienti.

Le nostre applicazioni web richiedono password forti secondo le raccomandazioni del NIST (NIST 800-63-3).

Gli account vengono bloccati per periodi di tempo esponenzialmente crescenti dopo un certo numero di tentativi di accesso non riusciti. Sia i tentativi di accesso riusciti che quelli falliti vengono registrati. Il recupero della password avviene tramite e-mail, dove vengono inviati solo i token. Le password non vengono mai inviate per e-mail. Le password nel database sono sottoposte a hash con una funzione di derivazione della chiave appropriata (non un semplice hash crittografico), utilizzando implementazioni standard e note. Ciò impedisce gli attacchi di forza bruta anche su un elenco noto di hash di password.

I nostri servizi web vengono aggiornati tramite una pipeline CI affidabile e revisionata. Le vulnerabilità dei moduli di terze parti vengono controllate tramite l'automazione parzialmente fornita da GitHub. I dispositivi utilizzano aggiornamenti firmware firmati e non caricano immagini non firmate o non attendibili. Il firmware può essere firmato solo attraverso un processo rigoroso e attentamente progettato che protegge adeguatamente le chiavi di firma.

Gli eventi verificabili vengono registrati e i log vengono raccolti in un repository centrale in tempo reale. Sono disponibili tracce di audit. Abbiamo un monitoraggio delle applicazioni per rilevare le anomalie. La registrazione non include mai i segreti ed è conforme al GDPR.

Gli sviluppatori sono consapevoli di SSRF, le revisioni del codice e la scansione statica aiutano a prevenire tali problemi. L'input dell'utente viene sanificato dove necessario per mitigare l'SSRF. Fa parte dei nostri test di penetrazione anche la verifica specifica di problemi simili.