Che cos'è Web application firewall di Azure?

Completato

In questa esercitazione 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 per aggiungere alla strategia complessiva di sicurezza di rete di Contoso.

Panoramica di Web application firewall di Azure

Potresti pensare che gli utenti malintenzionati non daranno importanza alle tue app web. Tuttavia, i test hanno indicato che i bot o gli attori malintenzionati verificano nuove app Web per individuare i punti deboli entro pochi minuti dalla distribuzione. Se si inserisce un'app sul Web, si supponga che gli attori delle minacce testeranno l'app per individuare le vulnerabilità quasi immediatamente. È anche possibile presupporre che tali probe continuino per la durata dell'app.

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

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

Un'attività comune nel ciclo di sviluppo delle app Web comporta la scrittura di codice per chiudere i fori 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, ad esempio SQL injection e scripting tra siti.

Diagramma di una rete virtuale di Azure con Web application firewall di Azure. I bot e le minacce vengono bloccati da un'app Web; sono consentite richieste legittime.

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

Funzionalità principali di Web application firewall di Azure

Per valutare Web application firewall di Azure, ecco alcune delle funzionalità importanti seguenti:

  • Regole gestite: il team di sicurezza di Microsoft crea, gestisce e aggiorna le regole usate da Web application firewall di Azure per rilevare e prevenire exploit comuni. Se viene modificata una regola o un set di regole (fare riferimento alla descrizione seguente), Microsoft aggiorna automaticamente e senza problemi Web application firewall di Azure.

    Annotazioni

    Non è possibile modificare o eliminare le regole gestite offerte da Web application firewall di Azure. Tuttavia, se una determinata regola è problematica per l'ambiente, ad esempio blocca il traffico legittimo verso 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 del bot: le regole del bot identificano bot validi e proteggono da bot non validi. I bot non valido vengono rilevati in base a Microsoft Threat Intelligence.

  • 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à. La modalità di rilevamento registra solo le richieste che violano una regola, mentre la modalità di prevenzione sia registra che blocca le richieste che violano una regola.

  • Elenchi di esclusione: è possibile configurare Web application firewall di Azure per ignorare 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 criteri di Web application firewall di Azure. È quindi possibile applicare tale criterio a più app Web per semplificare la gestione e la manutenzione.

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

  • Avvisi: Web application firewall di Azure si integra con Monitoraggio di Azure. Questa integrazione offre avvisi quasi in tempo reale quando WAF (Web Application Firewall) rileva una minaccia.

Attacchi comuni impediti da Web application firewall di Azure

La tabella seguente descrive i tipi più comuni di minacce malevole contro cui il Web Application Firewall di Azure aiuta a proteggere.

Minaccia Descrizione
Scripting intersito Un attore di minacce usa un'applicazione Web per inviare codice dannoso al Web browser di un altro utente. Il browser esegue il codice, che consente allo script di accedere ai dati di sessione, ai cookie e ad altre informazioni riservate dell'utente.
Inclusione di file locali Un utente malintenzionato sfrutta le vulnerabilità nella gestione da parte di un server delle istruzioni include, spesso negli script PHP. Passando testo appositamente configurato all'istruzione di include uno script, l'utente malintenzionato può includere file presenti localmente nel server. L'utente malintenzionato potrebbe quindi essere in grado di accedere a informazioni riservate ed eseguire comandi del server.
PHP injection L'utente malintenzionato inserisce testo appositamente configurato per ingannare il server nell'esecuzione di comandi PHP. Questi comandi consentono all'utente malintenzionato di eseguire codice PHP locale o remoto. L'utente malintenzionato potrebbe quindi essere in grado di accedere ai dati sensibili ed eseguire comandi nel server.
Attacchi al protocollo Un utente malintenzionato inserisce testo appositamente configurato in un'intestazione di richiesta HTTP/HTTPS. A seconda del testo specifico inserito nell'intestazione, l'utente malintenzionato può ingannare il server nella visualizzazione di dati sensibili o nell'esecuzione del codice.
Esecuzione di comandi remoti L'utente malintenzionato fa in modo che un server esegua comandi associati al sistema operativo del server. In un sistema UNIX, ad esempio, l'utente malintenzionato potrebbe eseguire il server ls per ottenere un elenco di directory.
Inclusione di file remoti Come l'inclusione di file locali, ma in questo caso l'attaccante invia al server testo appositamente configurato, che passa un file remoto—cioè un file su un server remoto controllato dall'attaccante—alla dichiarazione include di uno script.
Fissazione della sessione Un attaccante sfrutta una vulnerabilità dell'applicazione web che consente all'attaccante di ottenere un ID sessione valido. L'utente malintenzionato inganna un utente nell'autenticare una nuova sessione con tale ID. L'utente malintenzionato dirotta quindi questa sessione convalidata dall'utente.
Attacco di tipo SQL injection In un campo modulo Web, l'utente malintenzionato inserisce (o "inserisce") testo appositamente configurato per ingannare il server nell'esecuzione di comandi SQL. Questi comandi consentono all'utente malintenzionato di accedere a dati sensibili, inserire, aggiornare o eliminare dati o eseguire operazioni SQL.

Tutti gli exploit elencati nella tabella precedente sono possibili solo quando il server considera attendibile l'input ricevuto. Scrivere codice che controlla e purifica solo questi exploit sarebbe difficile e dispendioso in termini di tempo. Solo una piccola frazione dei possibili exploit che un'app Web può affrontare è rappresentata nella tabella precedente. Web application firewall di Azure è progettato per prevenire questi attacchi e molti altri.

Purificazione degli input

Le minacce affrontate dalle app Web moderne sono diverse e sofisticate. Tuttavia, nella maggior parte dei casi i motivi per cui gli exploit sono possibili è che l'app Web considera implicitamente attendibile l'input ricevuto.

Si consideri, ad esempio, un modulo Web che consente a un utente dell'app Web autorizzata di accedere all'account dell'utente. Il formato è costituito da soli tre elementi:

  • Casella di testo Nome utente
  • 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 tali variabili siano denominate userName rispettivamente e userPassword. Lo script eseguirà quindi l'istruzione seguente:

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

Ad esempio, se il nome utente è support e la password è 1234ABCD, la sql variabile ha il valore seguente:

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

L'app Web esegue questa istruzione SQL. Se viene restituito un record dalla query, l'app Web effettua l'accesso per l'utente.

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

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

In molti sistemi SQL, i trattini doppi (--) contrassegnano l'inizio di un commento. Tutti gli elementi successivi -- vengono ignorati, quindi l'istruzione precedente equivale al codice seguente:

SELECT * FROM users WHERE username='admin'

Supponendo che sia presente un utente denominato admin, questo comando autentica l'attaccante come utente amministratore; una violazione grave!

Diagramma di rete che illustra due tentativi di accesso, con Web application firewall di Azure che consente l'accesso autorizzato e nega l'accesso non autorizzato.

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

Web application firewall di Azure crea una barriera di non attendibilità tra un'app Web e l'input dell'utente. Web application firewall di Azure presuppone che tutto l'input sia potenzialmente dannoso, in modo da purificare l'input.

La purificazione dell'input comporta diversi aspetti a seconda del contesto. Ad esempio, la purificazione dell'input può significare rimuovere elementi di testo chiaramente pericolosi, ad esempio indicatori di commento SQL. Tuttavia, si verifica la purificazione, il risultato è l'input che può non danneggiare l'app Web o i relativi dati back-end.