Come i reverse proxy migliorano la sicurezza delle applicazioni web

Non è un segreto che le aziende utilizzino sempre più spesso le applicazioni web. Le applicazioni web consentono di semplificare le operazioni aziendali, di migliorare l'efficienza e di risparmiare sulle spese per attività che altrimenti verrebbero svolte manualmente. Nonostante la loro crescente popolarità, le applicazioni Web sono soggette a rischi e attacchi informatici. Questo articolo fornisce una panoramica

Non è un segreto che le aziende utilizzino sempre più spesso le applicazioni web. Le applicazioni web consentono di snellire le operazioni aziendali, di migliorare l'efficienza e di risparmiare sulle spese per attività che altrimenti verrebbero svolte manualmente.

Le applicazioni Web sono soggette a rischi e attacchi informatici nonostante la loro crescente popolarità. Questo articolo illustra i principali attacchi a cui un'applicazione web è vulnerabile. Scoprirete poi come incorporare un reverse proxy per ridurre al minimo le minacce.

Ma prima di immergerci negli aspetti della sicurezza, diamo un'occhiata all'architettura di una tipica applicazione web.

Panoramica dell'architettura delle applicazioni web

Applicazione web

Nella maggior parte dei casi, le applicazioni web sono costituite da server web e pagine web. I server Web accettano le richieste dei client (i browser Web), che vengono elaborate dal server Web e restituite al client.  

Mentre il lato server è codificato utilizzando linguaggi di programmazione dinamici come PHP, Python, ASP.NET e così via, il lato client è codificato utilizzando HTML, CSS e JavaScript.

Per ulteriori informazioni sulla struttura delle applicazioni web, è possibile consultare questo articolo. La figura seguente mostra una tipica comunicazione client-server.

Nel diagramma precedente, tutte le comunicazioni appaiono semplici, con le richieste che viaggiano avanti e indietro tra il client e il server. Tuttavia, non è sempre così.

Sfortunatamente, le applicazioni web che utilizzano la struttura sopra descritta sono soggette a cyberattacchi da parte di estranei tra il client e il server.

Diamo un'occhiata ad alcune delle statistiche più interessanti sugli attacchi informatici prima di immergerci nella natura di questi attacchi.

Quali sono le minacce significative per un'applicazione Web?

Statistiche entusiasmanti sui cyberattacchi

Secondo i dati di Positive Technologies sulle vulnerabilità delle applicazioni web del 2018, i settori finanziario e bancario hanno rappresentato il 28% di tutte le applicazioni web attaccate. Il dato indica inoltre che il 14% dei cyberattacchi ha come obiettivo le applicazioni online dei settori Telecom e Manufacturing, mentre l'11% ha come obiettivo le applicazioni dei trasporti.

Altri settori a rischio sono le istituzioni governative (11%), l'IT, l'e-commerce e i mass media.

Per quanto riguarda i tipi di attacchi, un altro rapporto di F5 afferma che gli attacchi di cross-site scripting (dal 4% al 54%) e di SQL injection (SQLi) (dal 15% al 76%) sono in aumento. 

Da queste statistiche si può concludere che sono necessarie alcune misure rigorose per proteggere le applicazioni web dalle vulnerabilità. Alcune delle falle di sicurezza si verificano a causa di problemi di codifica, mentre altre ragioni potrebbero essere dovute a un'infrastruttura inadeguata utilizzata dall'applicazione web. È qui che entra in gioco il Web Application Firewall (WAF), che può ridurre al minimo le vulnerabilità filtrando i pacchetti, bloccando il traffico HTTP e la registrazione non autorizzata. 

Lo analizzeremo più avanti. Prima di ciò, una breve panoramica delle principali minacce alla sicurezza.

Iniezione SQL (SQLi)

SQLi -SQL injection è una vulnerabilità della sicurezza web che consente all'aggressore di manipolare le query SQL che un'applicazione effettua sul database. Così facendo, ottiene l'accesso a informazioni potenzialmente preziose che chiunque non può raggiungere facilmente. 

Un esempio semplice e familiare è quello di sfruttare l'input dell'utente non sanificato a vantaggio dell'hacker. Supponiamo che ci sia una casella di testo che richiede l'ID utente. In base all'ID utente, la query recupera tutte le informazioni appartenenti a quell'utente.

Supponiamo che nella casella di testo l'utente abbia inserito il seguente testo:

Id utente: 228 o 1=1

La query risultante sarebbe la seguente:

SELECT * FROM Users WHERE UserId = 228 OR 1=1;

Quindi recupera tutti i dati della tabella dell'utente, comprese le password se la tabella contiene dati sulle password.

Per ulteriori informazioni su SQLi, potete fare riferimento a questo indirizzo.

Cross-Site Scripting (XSS)

L'XSS si verifica quando un utente inietta uno script dannoso, principalmente in JavaScript, attraverso campi di input non sanificati. Di solito, un aggressore invia questo script dannoso a un utente che non viene sospettato. Il browser dell'utente finale non sa che questo script è dannoso e lo esegue. 

Di conseguenza, questo script maligno può accedere a tutti i dati associati ai cookie, ai token di sessione o a qualsiasi altra informazione sensibile. Inoltre, questi script possono riscrivere l'HTML di una pagina web.

Autenticazione e gestione delle sessioni interrotte

Supponiamo che un utente debba accedere a un'applicazione Web utilizzando le credenziali di accesso. In questo caso, l'algoritmo proprietario del sito web genera un ID di sessione unico per l'intera comunicazione tra l'utente e il server web per quella sessione.

Se gli sviluppatori web non hanno crittografato i dati sicuri che viaggiano avanti e indietro tra l'utente e il server web, ci sono alte possibilità che un intruso li rubi e si comporti come l'utente. Questo scenario si verifica soprattutto quando ci si collega a Internet utilizzando il WiFi pubblico nei bar.

Per ulteriori dettagli si rimanda a questo articolo.

Quali sono i metodi per prevenire gli attacchi web?

Firewall per applicazioni web

Il WAF è una difesa di livello 7 del modello OSI che può essere posizionata nel punto di ingresso del server di destinazione, come mostrato nel diagramma seguente. Protegge la rete interna del server dagli attacchi e nasconde la topologia di rete del server.

Affinché il WAF funzioni, è necessario effettuare ulteriori configurazioni nel server. Come i firewall, il WAF filtra il traffico HTTP in entrata e in uscita che appare pericoloso per la rete interna del server se non soddisfa le regole impostate sul WAF.

Il WAF è anche un tipo di reverse proxy di cui parleremo nella prossima sezione.

Proxy inverso

Il compito di un server proxy è quello di nascondere l'indirizzo IP dell'utente e sostituirlo con quello del server proxy. Anche un reverse proxy fa lo stesso e migliora la sicurezza del server web nascondendo l'indirizzo IP e la topologia di rete interna del server.

Il client conosce solo l'indirizzo del server proxy e quindi il server reale è nascosto al client.

Idealmente, è possibile utilizzare un reverse proxy come un Web Application Firewall (WAF), di cui abbiamo parlato sopra. È possibile implementare il WAF sulle applicazioni Web sui dispositivi con reverse proxy configurato. Di conseguenza, il campo di applicazione del WAF per migliorare la sicurezza diventa più ampio. Inoltre, l'aggressore non è in grado di vedere la posizione effettiva del server web.

Si può fare riferimento a questo articolo per ulteriori informazioni fondamentali sui reverse proxy. Nella prossima sezione vedremo come utilizzare un reverse proxy per mitigare i rischi delle applicazioni. Tuttavia, prima di ciò, forniamo una panoramica di ciò che fa un reverse proxy.

Come funziona il reverse proxy?

Tutti i reverse proxy eseguono le seguenti operazioni fondamentali:

1. Il browser client invia una richiesta HTTP a un URL pubblico. Supponiamo che l'URL sia www.host.com sulla porta 80.
2. Quindi, come di consueto, il nome host si risolve intorno al server proxy inverso. Questo server proxy inverso ascolta questo indirizzo e riceve la richiesta.
3. Successivamente, il reverse proxy esamina l'URL per determinare dove deve instradare la richiesta. Di solito, un reverse proxy può utilizzare qualsiasi componente dell'URL per decidere dove instradare la richiesta. Ad esempio, può utilizzare host, protocollo, percorso, porta o stringa di query. Di solito, il percorso è il componente principale che decide l'instradamento.
   1. Le impostazioni di configurazione del Reverse proxy determinano l'URL in uscita a cui inviare la richiesta. Questo URL in uscita è solitamente il server back-end responsabile della fornitura dei contenuti. Il server proxy inverso può riscrivere le parti della richiesta. Potrebbe, ad esempio, modificare o aggiungere segmenti di percorso.
   2. Il proxy inverso deve anche aggiornare alcune informazioni dell'intestazione HTTP per indicare il server web interno, oltre a rimappare l'URL. L'intestazione "Host:", ad esempio, contiene il nome dell'host da cui viene richiesto l'URL.
   3. Per concludere la mappatura degli URL, http://www.host.com potrebbe essere rimappato in http://realhost.com:8080.As, come si può vedere in questo caso l'hostname è cambiato in realhost. Anche il numero di porta è cambiato in 8080.

4. Infine, il reverse proxy invia la richiesta al server reale, che la elabora.
5. Dopo aver elaborato la richiesta, il server invia la risposta al reverse proxy.
6. Il reverse proxy esegue le seguenti operazioni:
   1. Modifica la risposta per inviarla correttamente al client. Questo include il campo "Location:", che contiene la posizione del server del file.
   2. Il proxy inverso rimappa le intestazioni e infine invia la risposta al client.

Come proteggere l'applicazione web con il reverse proxy

Poiché il nostro obiettivo è quello di superare i cyberattacchi menzionati in precedenza, il reverse proxy deve svolgere ulteriori funzionalità oltre a quelle menzionate in precedenza.

Convalida del contenuto della richiesta

Quando un client invia una richiesta al server, il reverse proxy sanifica l'input confrontandolo con il suo database di firme. I programmatori sviluppano queste firme con espressioni regolari molto avanzate. La decisione del reverse proxy di consentire la richiesta con l'input dell'utente si baserà esclusivamente sull'approccio dei filtri blocklist e whitelist.

Approccio del filtro della lista nera

Il filtro blacklist memorizza le richieste dannose conosciute. Quindi confronta ogni richiesta con le voci dell'elenco. Se trova una corrispondenza, rifiuta la richiesta. Le diverse varianti della stessa aggressione devono essere registrate separatamente nell'elenco. La completezza della lista nera contribuisce alla sua efficacia. 

Approccio del filtro whitelist

Un filtro whitelist cattura l'intera raccolta di richieste valide per un sito specifico. Di conseguenza, la white list previene gli attacchi consentendo solo alle richieste conosciute di raggiungere il server. Il processo di costruzione di una white list, d'altra parte, richiede molto tempo e la conoscenza dell'intera gamma di richieste legittime che un utente può potenzialmente inviare a un server. 

Inoltre, può risultare eccessivo creare tutte le richieste valide a centinaia di migliaia di fornitori di database in caso di SQL injection.

Qualsiasi modifica a un'applicazione Web protetta richiede un aggiornamento della whitelist. Di conseguenza, il mantenimento di una whitelist aumenta il carico amministrativo. 

Convalida del contenuto della risposta

Prima di inviare la risposta dal server al client, il reverse proxy la convalida. Per fare questo, di solito, viene utilizzata una lista nera. Il filtro della blacklist può nascondere le risposte note ai client che non hanno bisogno di vederle. I messaggi di errore sono un esempio di questo tipo di dati; il reverse proxy può sostituire l'errore con un messaggio di errore generico che non contiene dati sensibili.

Registrazione delle richieste e delle risposte

Il reverse proxy può anche registrare la richiesta per un esame successivo. L'approccio migliore è quello di configurare il log solo per le richieste che il reverse proxy ha bloccato inizialmente. È necessario esaminare attentamente i log durante le prime fasi dell'installazione. Questo è essenziale per verificare che il reverse proxy non blocchi alcuna richiesta autentica.

Conclusione

In questo articolo ci auguriamo che comprendiate le vulnerabilità di un'applicazione web e come potete utilizzare un reverse proxy per risolvere queste minacce. In effetti, il reverse proxy non eliminerà tutte le possibili vulnerabilità associate alle applicazioni web.

Tuttavia, sarebbe un'ottima strategia per mitigare la maggior parte delle minacce che si incontrano in un'applicazione web. Infine, speriamo che applicherete i concetti appresi in questo articolo nel caso in cui doveste riscontrare problemi di sicurezza nella vostra applicazione web.