Sviluppare applicazioni sicure in Azure
In questo articolo vengono presentate attività e controlli di sicurezza da considerare quando si sviluppano applicazioni per il cloud. Vengono analizzate le domande e i concetti di sicurezza da considerare durante le fasi di implementazione e verifica di Microsoft Security Development Lifecycle (SDL). L'obiettivo è consentire di definire le attività e i servizi di Azure che è possibile usare per sviluppare un'applicazione più protetta.
Questo articolo tratta le fasi di SDL seguenti:
- Implementazione
- Verifica
Implementazione
L'obiettivo della fase di implementazione consiste nel definire le procedure consigliate per la prevenzione anticipata e per rilevare e rimuovere i problemi di sicurezza dal codice. Si supponga che l'applicazione venga usata in modi in cui non si intende usarla. Ciò consente di evitare un uso improprio accidentale o intenzionale dell'applicazione.
Eseguire revisioni del codice
Prima di archiviare il codice, eseguire revisioni del codice per aumentare la qualità complessiva del codice e ridurre il rischio di creare bug. È possibile usare Visual Studio per gestire il processo di revisione del codice.
Eseguire l'analisi codice statico
L'analisi del codice statico (nota anche come analisi del codice sorgente) viene eseguita come parte di una revisione del codice. L'analisi del codice statico si riferisce comunemente all'esecuzione di strumenti di analisi del codice statico per trovare potenziali vulnerabilità nel codice non in esecuzione. L'analisi del codice statico usa tecniche come il controllo dei taint e l'analisi del flusso di dati.
Azure Marketplace offre strumenti di sviluppo che eseguono l'analisi codice statico e assistono nelle revisioni del codice.
Convalidare e purificare tutti gli input per l'applicazione
Considerare tutti gli input come non attendibili per proteggere l'applicazione dalle vulnerabilità più comuni delle applicazioni Web. I dati non attendibili sono un veicolo per gli attacchi injection. L'input per l'applicazione include parametri nell'URL, input dell'utente, dati dal database o da un'API e tutto ciò che viene passato e che un utente potrebbe potenzialmente manipolare. Un'applicazione deve convalidare che i dati siano sintatticamente e semanticamente validi prima che l'applicazione li usi in qualunque modo, inclusa la visualizzazione all'utente.
Convalidare l'input all'inizio del flusso di dati per garantire che solo i dati in formato corretto entrino nel flusso di lavoro. I dati in formato non valido non devono essere salvati nel database o causare il malfunzionamento di un componente downstream.
Blocklisting e allowlisting sono due approcci generali per eseguire la convalida della sintassi di input:
L'elenco di blocchi tenta di verificare che un determinato input utente non contenga contenuto "noto per essere dannoso".
Consenti l'elenco dei tentativi di verificare che un determinato input utente corrisponda a un set di input "noti". L'elenco consentito basato su caratteri è una forma di consentilisting in cui un'applicazione verifica che l'input utente contenga solo caratteri "noti validi" o che l'input corrisponda a un formato noto.
Ad esempio, ciò potrebbe comportare la verifica che un nome utente contenga solo caratteri alfanumerici o che contenga esattamente due numeri.
Allowlisting è l'approccio preferito per la creazione di software sicuro. L'elenco di blocchi è soggetto a un errore perché è impossibile pensare a un elenco completo di input potenzialmente non valido.
Eseguire questa operazione sul server, non sul lato client o sul server e sul lato client.
Verificare l'output dell'applicazione
Qualsiasi output presentato in modo visivo o all'interno di un documento deve essere sempre codificato e preceduto da un carattere di escape. L'escape, noto anche come codifica di output, viene usato per garantire che i dati non attendibili non siano un veicolo per un attacco injection. L'escape, combinato con la convalida dei dati, fornisce difese a più livelli per aumentare la sicurezza del sistema nel suo complesso.
L'uscita assicura che tutto sia visualizzato come output. Escaping consente anche all'interprete di sapere che i dati non devono essere eseguiti e ciò impedisce l'esecuzione di attacchi. Si tratta di un'altra tecnica di attacco comune denominata cross-site scripting (XSS).
Se si usa un framework Web di terze parti, è possibile verificare le opzioni per la codifica di output nei siti Web usando il foglio di prevenzione XSS OWASP.
Usare query con parametri quando si contatta il database
Non creare mai una query di database inline "in tempo reale" nel codice e inviarla direttamente al database. Il codice dannoso inserito nell'applicazione potrebbe potenzialmente causare il furto, la cancellazione o la modifica del database. L'applicazione può essere usata anche per eseguire comandi del sistema operativo dannosi sul sistema operativo che ospita il database.
Usare invece query con parametri o stored procedure. Quando si usando query con parametri, è possibile richiamare la procedura dal codice in modo sicuro e passarla a una stringa senza preoccuparsi che venga trattata come parte dell'istruzione di query.
Rimuovi intestazioni server standard
Intestazioni come Server, X-Powered-By e X-AspNet-Version rivelano informazioni sul server e sulle tecnologie sottostanti. È consigliabile eliminare queste intestazioni per evitare l'impronta digitale dell'applicazione. Vedere Rimozione di intestazioni server standard nei siti Web di Azure.
Separare i dati di produzione
I dati di produzione o i dati "reali" non devono essere usati per lo sviluppo, il test o qualsiasi altro scopo rispetto a quello previsto dall'azienda. È necessario usare un set di dati mascherato (anonimizzato) per tutte le attività di sviluppo e test.
Ciò significa che un minor numero di utenti ha accesso ai dati reali, riducendo così la superficie di attacco. Significa anche che un minor numero di dipendenti visualizza i dati personali, eliminando una potenziale violazione della riservatezza.
Implementare criteri password complessi
Per proteggersi da attacchi di forza bruta e attacchi a dizionario è necessario implementare criteri password complessi, per fare in modo che gli utenti creino password complesse, ad esempio con una lunghezza minima di 12 caratteri o con caratteri speciali e alfanumerici.
Azure Active Directory B2C consente di gestire le password, fornendo la reimpostazione della password self-service, forzare la reimpostazione della password e altro ancora.
Per difendersi da attacchi ad account predefiniti, verificare che tutte le chiavi e le password siano sostituibili e che vengano generate o sostituite dopo la fase di installazione.
Se l'applicazione deve generare automaticamente le password, assicurarsi che le password generate siano casuali e che abbiano un'entropia elevata.
Convalidare caricamenti di file
Se l'applicazione consente il caricamento dei file, tenere in considerazione le precauzioni che è possibile prendere per questa attività rischiosa. Il primo passaggio di molti attacchi è inserire del codice dannoso in un sistema sotto attacco. Il caricamento di un file consente all'utente malintenzionato di portare a termine questa operazione. OWASP offre soluzioni per la convalida di un file, in modo da garantire la sicurezza del file che si sta caricando.
È consigliabile installare una protezione antimalware per identificare e rimuovere virus, spyware e altro software dannoso. È possibile installare Microsoft Antimalware o una soluzione di protezione degli endpoint del partner Microsoft (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows e Endpoint Protection).
Microsoft Antimalware include caratteristiche come la protezione in tempo reale, l'analisi pianificata, il monitoraggio e aggiornamento malware, l'aggiornamento delle firme e del motore, il reporting di campioni e la raccolta degli eventi di esclusione. È possibile integrare Microsoft Antimalware e soluzioni partner con Microsoft Defender per Cloud per semplificare la distribuzione e i rilevamenti predefiniti (avvisi e eventi imprevisti).
Non memorizzare nella cache contenuto sensibile
Non memorizzare nella cache contenuto sensibile del browser. I browser possono archiviare informazioni per la memorizzazione nella cache e la cronologia. Questi file memorizzati nella cache vengono archiviati in una cartella, come la cartella Temporary Internet Files, nel caso di Internet Explorer. Quando queste pagine vengono visitate di nuovo, il browser le visualizza dalla cache. Se le informazioni riservate (indirizzo, dettagli carta di credito, numero di sicurezza sociale, nome utente) vengono visualizzate all'utente, le informazioni potrebbero essere archiviate nella cache del browser e recuperabili esaminando la cache del browser o premendo il pulsante Indietro del browser.
Verifica
La fase di verifica prevede un impegno completo per garantire che il codice soddisfi i principi di sicurezza e privacy stabiliti nelle fasi precedenti.
Trovare e correggere le vulnerabilità nelle dipendenze dell'applicazione
È possibile analizzare l'applicazione e le librerie dipendenti per identificare i componenti vulnerabili noti. I prodotti disponibili per eseguire questa analisi includono OWASP Dependency Check, Snyk e Black Duck.
Testare l'applicazione in uno stato operativo
Il test della sicurezza dell'applicazione dinamico (DAST) è un processo di test di un'applicazione in uno stato operativo per individuare le vulnerabilità della sicurezza. Gli strumenti DAST analizzano i programmi durante l'esecuzione per trovare vulnerabilità di sicurezza, ad esempio danneggiamento della memoria, configurazione del server non sicura, scripting tra siti, problemi relativi ai privilegi utente, inserimento SQL e altri problemi di sicurezza critici.
Il DAST è diverso dal test di sicurezza dell'applicazione statico (SAST). Gli strumenti SAST analizzano il codice sorgente o le versioni compilate del codice quando il codice non è in esecuzione per individuare i difetti di sicurezza.
Eseguire il DAST preferibilmente con l'assistenza di un professionista della sicurezza, come un tester della penetrazione o un analizzatore della vulnerabilità. Se non è disponibile un professionista della sicurezza, è possibile eseguire il DAST con uno scanner proxy Web e training. Collegare uno scanner DAST in anticipo per assicurarsi di non introdurre problemi di sicurezza evidenti nel codice. Per un elenco di scanner delle vulnerabilità delle applicazioni Web, vedere il sito OWASP.
Eseguire test con dati casuali
Nel test con dati casuali, si induce l'errore del programma introducendo intenzionalmente dati non validi o casuali in un'applicazione. Inducendo un errore del programma, è possibile rivelare potenziali problemi di sicurezza prima del rilascio dell'applicazione.
Security Risk Detection è il servizio esclusivo Microsoft per il test con dati casuali, che consente di individuare i bug critici per la sicurezza nel software.
Eseguire la verifica della superficie di attacco
Esaminare la superficie di attacco dopo il completamento del codice consente di verificare che siano state prese in considerazione tutte le modifiche di progettazione o implementazione di un'applicazione o di un sistema. Consente di garantire che tutti i nuovi vettori di attacco creati in seguito alle modifiche, inclusi i modelli di rischio, siano stati esaminati e mitigati.
È possibile avere un quadro della superficie di attacco analizzando l'applicazione. Microsoft offre uno strumento di analisi della superficie di attacco, denominato Attack Surface Analyzer. È possibile scegliere tra molti strumenti di analisi dinamica e vulnerabilità commerciali, tra cui OWASP Attack Surface Detector, Arachni e w3af. Questi strumenti di analisi eseguono la ricerca per indicizzazione dell'app e mappano le parti dell'applicazione accessibili tramite Web. È anche possibile eseguire ricerche in Azure Marketplace per strumenti di sviluppo simili.
Eseguire test di penetrazione della sicurezza
Verificare che l'applicazione sia protetta è importante come testare qualsiasi altra funzionalità. È necessario rendere i test di penetrazione parte integrante del processo di compilazione e distribuzione. Pianificare test di sicurezza e analisi delle vulnerabilità periodici sulle applicazioni distribuite, monitorando eventuali porte aperte, endpoint e attacchi.
Eseguire test di verifica della sicurezza
La soluzione Di sicurezza del tenant di Azure (AzTS) di Secure DevOps Kit per Azure (AzSK) contiene STS per più servizi della piattaforma Azure. Questi SVT vengono eseguiti periodicamente, per assicurarsi che la sottoscrizione di Azure e le diverse risorse che costituiscono l'applicazione siano in uno stato sicuro. È anche possibile automatizzare questi test usando la funzionalità di integrazione continua/distribuzione continua (CI/CD) di AzSK, che rende disponibili gli SVT come estensione di Visual Studio.
Passaggi successivi
Negli articoli seguenti si consigliano controlli di sicurezza e attività che consentono di progettare e distribuire applicazioni sicure.