Che cos'è Web application firewall di Azure?

Completato

In questa unità verranno illustrate le nozioni di base di Web application firewall di Azure. Questa panoramica consente di valutare se Web application firewall di Azure è uno strumento utile in aggiunta alla strategia di sicurezza di rete complessiva di Contoso.

Panoramica di Web application firewall di Azure

Si potrebbe pensare che utenti malintenzionati non siano interessati alle app Web. Tuttavia, i test hanno indicato che i bot o gli attori malintenzionati analizzano nuove app Web per rilevare eventuali debolezze entro pochi minuti dalla distribuzione. Se si inserisce un'app sul Web, si deve presupporre che questa verrà analizzata da malintenzionati quasi immediatamente per verificarne le vulnerabilità. È anche possibile presupporre che tali analisi continueranno per l'intera durata dell'app.

La maggior parte dei test dannosi delle app Web verifica la presenza di una o più vulnerabilità comuni. Se rilevate, un malintenzionato può usare queste vulnerabilità per eseguire attacchi come gli exploit seguenti:

  • SQL injection
  • Scripting intersito
  • Inclusione di file locali e remoti
  • Attacchi flood HTTP/HTTPS
  • Attacchi di bot dannosi

Un'attività comune nel ciclo di sviluppo di app Web prevede la scrittura di codice per chiudere i buchi di sicurezza più comuni. La scrittura del codice di sicurezza richiede tempo, competenze e test.

Web application firewall di Azure è un servizio di Azure che offre una protezione centralizzata delle app Web ospitate in Azure. Web application firewall di Azure protegge le app Web da minacce comuni come SQL injection e scripting intersito.

Diagram of an Azure virtual network with Azure Web Application Firewall. Bots and threats are blocked from a web app; legitimate requests are allowed.

È possibile distribuire Web application firewall di Azure in pochi minuti. Le app Web ottengono immediatamente una protezione avanzata dalle minacce note, il tutto senza scrivere una sola riga di codice di sicurezza.

Funzionalità chiave di Web application firewall di Azure

Per semplificare la valutazione di Web application firewall di Azure, di seguito sono riportate alcune delle sue importanti funzionalità:

  • Regole gestite: le regole usate da Web application firewall di Azure per rilevare e impedire gli exploit comuni vengono create, gestite e aggiornate dal team di sicurezza di Microsoft. Se una regola cambia o viene modificato un set di regole (fare riferimento alla descrizione seguente), Microsoft aggiorna Web application firewall di Azure automaticamente e senza interruzioni.

    Nota

    Non è possibile modificare o eliminare le regole gestite offerte da Web application firewall di Azure. Tuttavia, se una particolare regola è problematica per l'ambiente in uso, ad esempio blocca il traffico legittimo per l'app Web, è possibile creare esclusioni o disabilitare la regola o il set di regole. È anche possibile creare regole personalizzate per sovrascrivere il comportamento predefinito.

  • Regole dei bot: le regole dei bot identificano i bot validi e proteggono da quelli non validi. I bot non validi vengono rilevati in base all'intelligence sulle minacce Microsoft.

  • Regole personalizzate: se le regole gestite offerte da Web application firewall di Azure non coprono una minaccia specifica per l'applicazione Web, è possibile creare una regola personalizzata.

  • Modalità: Web application firewall di Azure può funzionare in una delle due modalità seguenti: la modalità di rilevamento si limita a registrare le richieste che violano una regola, mentre la modalità di prevenzione le registra e le blocca.

  • Elenchi di esclusione: è possibile configurare Web application firewall di Azure perché ignori attributi specifici quando controlla le richieste.

  • Criteri: è possibile combinare un set di regole gestite, regole personalizzate, esclusioni e altre impostazioni di Web application firewall di Azure in un singolo elemento denominato criterio di Web application firewall di Azure. È quindi possibile applicare tale criterio a più app Web per semplificare la gestione e la manutenzione.

  • Limiti di dimensioni delle richieste: è possibile configurare Web application firewall di Azure perché contrassegni le richieste troppo piccole o troppo grandi.

  • Avvisi: Web application firewall di Azure si integra con Monitoraggio di Azure. Questa integrazione offre avvisi in near real-time quando WAF rileva una minaccia.

Attacchi comuni impediti da Web application firewall di Azure

La tabella seguente descrive i tipi più comuni di minacce dannose da cui Web application firewall di Azure contribuisce a proteggere.

Minaccia Descrizione
Scripting intersito Un attore malintenzionato usa un'applicazione Web per inviare codice dannoso al browser Web di un altro utente. Il browser esegue il codice, che consente allo script di accedere ai dati della sessione, ai cookie e ad altre informazioni riservate dell'utente.
Inclusione di file locali Un utente malintenzionato sfrutta le vulnerabilità nella gestione delle istruzioni include di un server, più spesso negli script PHP. Passando un testo appositamente configurato all'istruzione include di uno script, l'utente malintenzionato può includere i file presenti localmente nel server. L'utente malintenzionato può quindi riuscire ad accedere a informazioni riservate ed eseguire comandi del server.
PHP injection L'utente malintenzionato inserisce un testo appositamente configurato per indurre il server a eseguire comandi PHP. Questi comandi consentono all'utente malintenzionato di eseguire un codice PHP locale o remoto. L'utente malintenzionato può quindi riuscire ad accedere ai dati sensibili ed eseguire comandi nel server.
Attacchi ai protocolli Un utente malintenzionato inserisce testo appositamente configurato in un'intestazione della richiesta HTTP/HTTPS. A seconda del testo specifico inserito nell'intestazione, l'utente malintenzionato può indurre il server a visualizzare dati sensibili o eseguire un codice.
Attacchi di tipo Remote Command Execution L'utente malintenzionato induce un server a eseguire comandi associati al sistema operativo del server. In un sistema UNIX, ad esempio, l'utente malintenzionato può forzare il server a eseguire ls per ottenere un elenco di directory.
Inclusione di file remoti Equivale agli attacchi di tipo Local File Inclusion, ad eccezione del fatto che l'utente malintenzionato invia un testo configurato appositamente per il server che passa un file remoto, ovvero un file in un server remoto controllato dall'utente malintenzionato, a un'istruzione include dello script.
Fissazione sessione Un utente malintenzionato sfrutta una vulnerabilità dell'app Web che gli consente di ottenere un ID di sessione valido. L'utente malintenzionato induce un utente ad autenticarsi in una nuova sessione con tale ID. L'utente malintenzionato dirotta quindi questa sessione convalidata dall'utente.
SQL injection In un campo modulo Web, l'utente malintenzionato inserisce un testo appositamente configurato per indurre il server a eseguire comandi SQL. Questi comandi consentono all'utente malintenzionato di accedere a dati sensibili, inserire, aggiornare o eliminare dati oppure eseguire operazioni SQL.

Tutti gli exploit elencati nella tabella precedente sono possibili solo quando il server considera attendibile l'input ricevuto. La scrittura di codice che controlla e purifica solo questi exploit sarebbe difficile e dispendiosa in termini di tempo. Nella tabella precedente è rappresentata solo una piccola parte dei possibili exploit che un'app Web può trovarsi ad affrontare. Web application firewall di Azure è progettato per impedire questi attacchi e molto altro ancora.

Purificazione degli input

Le minacce affrontate dalle moderne app Web sono molteplici e sofisticate. Tuttavia, nella maggior parte dei casi, è possibile che l'app Web consideri implicitamente attendibile l'input ricevuto.

Si consideri, ad esempio, un modulo Web che consente a un utente di un'app Web autorizzato di accedere al proprio account. Il modulo è costituito solo da tre elementi:

  • Una casella di testo Nome utente
  • Una casella di testo Password
  • Un pulsante Accedi

Quando un utente autorizzato compila il modulo e seleziona Accedi, uno script dell'app Web archivia il nome utente e la password nelle variabili. Si supponga che le variabili siano rispettivamente denominate userName e userPassword. Lo script eseguirà quindi l'istruzione seguente:

sql = "SELECT * FROM users WHERE username='" + userName + "' AND password='" + userPassword + "'"

Se ad esempio il nome utente è support e la password è 1234ABCD, la variabile sql avrà il valore seguente:

SELECT * FROM users WHERE username='support' AND password='1234ABCD'

L'app Web esegue questa istruzione SQL. Se dalla query viene restituito un record, l'app consente all'utente di accedere.

Si supponga ora che un utente malintenzionato inserisca admin'-- nel campo Nome utente e lasci vuoto il campo Password. In questo caso, l'istruzione SQL risultante è la seguente:

SELECT * FROM users WHERE username='admin'--' AND password=''

In molti sistemi SQL, i doppi trattini (--) indicano l'inizio di un commento. Tutto ciò che segue -- viene ignorato, quindi l'istruzione precedente è equivalente al codice seguente:

SELECT * FROM users WHERE username='admin'

Supponendo che sia presente un utente denominato admin, questo comando effettuerà l'accesso dell'utente malintenzionato come utente amministratore, una grave violazione.

Network diagram depicting two sign-in attempts, with Azure Web Application Firewall allowing the authorized sign-in and denying the unauthorized sign-in.

L'esempio precedente è un'istanza di un exploit denominato SQL injection. Gli utenti malintenzionati possono sfruttare i vantaggi di SQL injection e altri exploit nelle app Web che considerano attendibili tutti gli input.

Web application firewall di Azure crea una barriera di non attendibilità tra un'app Web e il relativo input utente. Web application firewall di Azure presuppone che tutti gli input siano potenzialmente dannosi, quindi li purifica.

La purificazione degli input implica diversi elementi, a seconda del contesto. Ad esempio, la purificazione degli input può implicare la rimozione di elementi di testo chiaramente pericolosi, ad esempio indicatori di commento SQL. Comunque venga effettuata la purificazione, il risultato è un input che non può nuocere all'app Web o ai relativi dati di back-end.