volete aiutarci? Ecco le opzioni disponibili:","Crunchbase","Chi siamo","Grazie a tutti per l'incredibile supporto!","Collegamenti rapidi","Programma di affiliazione","Premio","ProxyScrape prova premium","Controllore di proxy online","Tipi di proxy","Paesi proxy","Casi d'uso del proxy","Importante","Informativa sui cookie","Esclusione di responsabilità","Informativa sulla privacy","Termini e condizioni","Media sociali","Facebook","LinkedIn","Twitter","Quora","Telegramma","Discordia","\n © Copyright 2024 - Thib BV | Brugstraat 18 | 2812 Mechelen | Belgio | IVA BE 0749 716 760\n"]}
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.
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.
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.
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.
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.
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.
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.
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.
Tutti i reverse proxy eseguono le seguenti operazioni fondamentali:
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.
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.
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.
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.
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.
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.
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.