22 Vulnerabilità comuni delle applicazioni Web da conoscere
Pubblicato: 2021-10-14Le aziende "spostano costantemente a sinistra" e sfruttano le esperienze innovative di clienti e dipendenti fornite dalle applicazioni basate sul cloud. Allo stesso tempo, anche i malintenzionati rivedono continuamente le loro strategie di attacco per adattarsi a questo cambiamento.
Per preservare la privacy e la sicurezza dei dati, è fondamentale che le aziende cerchino protezione contro queste 22 vulnerabilità comuni delle applicazioni web .
Controllo accessi danneggiato
I controlli di accesso sono responsabili del modo in cui gli utenti interagiscono con risorse e dati, nonché di ciò che possono modificare e/o leggere. Una vulnerabilità errata del controllo degli accessi è possibile quando l'utente è in grado di coinvolgere i dati in un modo che non è davvero necessario. Ad esempio, se l'utente dovrebbe essere solo in grado di leggere i dettagli di pagamento ma in realtà ha la capacità di modificarli, una situazione del genere esemplifica un controllo di accesso interrotto. Gli aggressori dannosi sfruttano questa vulnerabilità per ottenere l'accesso non autorizzato a software, reti e sistemi. Possono quindi sfruttare la situazione, concedere all'ID utente un maggiore accesso all'infrastruttura, per compromettere la disponibilità, la riservatezza o l'integrità dei dati.
Autenticazione danneggiata
Le vulnerabilità delle applicazioni Web associate all'autenticazione danneggiata o interrotta derivano anche dall'accesso degli utenti. In questo caso, tuttavia, gli aggressori dannosi influiscono negativamente sui dati che confermano l'identità di un utente, ad esempio tramite il dirottamento di token di sessione, chiavi o password. L'attaccante malintenzionato ottiene l'accesso non autorizzato al software, ai sistemi e alle reti perché l'organizzazione non è stata in grado di impostare correttamente identità e controlli di gestione degli accessi.
Iniezione Carriage Return e Line Feed (CRLF).
Il ritorno a capo agisce come un comando che denota l'inizio di una riga di codice, tipicamente indicata come /r. L'avanzamento riga è invece un comando che denota la fine di una riga di codice, generalmente indicata come /n. Come molti altri software, ogni sistema operativo utilizza diverse combinazioni di ritorno a capo e avanzamento riga. Quando gli aggressori dannosi sono coinvolti nelle iniezioni di CRLF, il codice immesso altera il modo in cui l'applicazione Web reagisce ai comandi. Questo può essere utilizzato per divulgare dati sensibili o eseguire codice.
Trasformazione di cifratura insicura
Cifra, che è un termine standard per "algoritmo di crittografia", è in realtà la matematica alla base di un processo di crittografia o decrittografia. La trasformazione si riferisce allo schema delle operazioni eseguite sull'input per fornire l'output atteso. Pertanto, una trasformazione di cifratura si riferisce al numero di operazioni che convertono i dati crittografati illeggibili in dati leggibili e decrittografati. Una vulnerabilità insicura di trasformazione della cifratura descrive che l'algoritmo di crittografia può essere facilmente violato, sabotando in definitiva l'essenza della crittografia in prima istanza.
Componenti con evidenti vulnerabilità
Ogni applicazione web dipende da altri componenti per funzionare. Ad esempio, se si esegue un'applicazione su un server Web o applicativo senza patch, il server è la parte con evidenti vulnerabilità. L'elenco delle vulnerabilità e delle esposizioni comuni (CVE) comprende tutte le vulnerabilità di sicurezza note. Poiché gli aggressori malintenzionati sono a conoscenza dell'elenco, cercano spesso componenti senza adeguati aggiornamenti delle patch di sicurezza. Nel momento in cui possono infiltrarsi in un componente dell'applicazione Web, possono anche ottenere l'accesso ai dati dell'applicazione.
Politica di condivisione delle risorse tra le origini (CORS).
Tutte le applicazioni basate sul Web utilizzano un URL come mezzo per connettere il browser dell'utente al suo server. La stessa politica di origine è una protezione comune. In linea con ciò, il server risponderà solo a un URL con lo stesso protocollo, schema di percorso e nome di dominio di primo livello. Ciò significa che puoi accedere a http://organization.com/page1 e http://organization.com/page2 perché entrambi condividono quanto segue:
- Protocollo: HTTP
- Dominio: Company.com
- Schema del percorso: /pagina#
Sebbene sia sicura, la stessa politica di origine è restrittiva quando si tratta di app basate sul Web che richiedono l'accesso a risorse che si connettono a terze parti o sottodomini.
Una politica CORS concede al browser l'autorizzazione a visualizzare queste risorse correlate stabilendo un numero di intestazioni HTTP consentite considerate "attendibili". Ad esempio, un'applicazione potrebbe dover attingere dati da due database su server Web separati. La stesura di un particolare elenco "consentito" diventa un lavoro eccessivo poiché includi server aggiuntivi. Poiché entrambi i server stanno "condividendo" l'applicazione, l'azienda scrive una politica CORS che consente ai browser di connettersi a entrambi. Se una politica CORS, tuttavia, non è definita correttamente, la politica può consentire ai server di concedere l'accesso quando richiesto da un utente malintenzionato.
Gestione delle credenziali
Le credenziali utente comprendono un ID utente e una passkey. L'utente deve fornire entrambe le informazioni nella pagina di accesso prima di ottenere l'accesso a un'applicazione. Tuttavia, i database tendono a utilizzare una crittografia debole oa mantenere le informazioni in chiaro. Una cattiva gestione delle credenziali consente agli aggressori di rubare facilmente le credenziali e sfruttarle per ottenere l'accesso alle applicazioni web.
Falsificazione di richieste tra siti (CSRF)
Un attacco CSRF utilizza metodologie di ingegneria sociale per spingere un utente a modificare le informazioni, come password o nomi utente, in un'applicazione. Un CSRF, a differenza degli attacchi di cross-site scripting (XXS) o del malware, richiede che un utente sia connesso all'applicazione che utilizza solo i cookie di sessione per convalidare le richieste dell'utente o tenere traccia delle sessioni. Nel momento in cui l'utente esegue l'azione prevista, l'attore malintenzionato utilizza il browser per eseguire la parte restante dell'attacco, ad esempio lo spostamento di fondi, senza che l'utente sappia cosa è successo.
Scripting tra siti (XXS)
A differenza di un CSRF che richiede all'utente di accedere a un'app per essere indotto con l'inganno a modificare determinate informazioni, un attacco XXS richiede che l'attaccante malintenzionato inserisca codice in una pagina Web, in genere in alcuni componenti della pagina come un'immagine. Una volta che un utente avvia la pagina Web sul proprio browser, il codice errato inizia a essere scaricato ed eseguito nel browser. Ad esempio, il codice dannoso può reindirizzare l'utente da un sito credibile a uno illegittimo.
Indicizzazione delle directory
Di solito, i server Web delineano tutti i file salvati su di essi in un'unica directory. Quando un utente desidera individuare un determinato file in un'applicazione Web, di solito aggiunge il nome del file nella richiesta. Nel caso in cui il file non sia disponibile, l'applicazione presenterà all'utente un elenco di tutti i file indicizzati, in modo che l'utente abbia la possibilità di selezionare qualcos'altro.
Tuttavia, i file vengono indicizzati automaticamente dai server web. Quando l'applicazione presenta un elenco di tutti i file archiviati, un malintenzionato che sfrutta le vulnerabilità nell'indice della directory può ottenere l'accesso ai dati che possono fornire loro maggiori informazioni sul sistema. Ad esempio, possono conoscere gli account utente personali o le convenzioni di denominazione. Questi due punti dati possono essere sfruttati per effettuare attacchi di furto di credenziali o svelare informazioni sensibili.
Attraversamento delle directory
Conosciuta anche come attacco di backtracking, dot-dot-slash e directory climbing, la vulnerabilità di attraversamento delle directory sfrutta il modo in cui un'applicazione riceve i dati dal server web. Gli elenchi di controllo di accesso (ACL) generalmente limitano l'accesso degli utenti a determinati file all'interno di una directory principale. Gli aggressori dannosi che utilizzano la modalità di vulnerabilità dell'attraversamento della directory individuano il formato URL utilizzato dall'applicazione per richiedere i file.
Incapsulamento
Diversamente da alcune delle altre vulnerabilità comuni delle applicazioni Web nell'elenco, la vulnerabilità dell'incapsulamento sfrutta i difetti nel modo in cui uno sviluppatore ha codificato l'applicazione. L'incapsulamento è un termine di programmazione che si riferisce al raggruppamento di dati e azioni che possono essere eseguite su tali dati in una sola unità. L'incapsulamento protegge i dati nascondendo le informazioni su come viene eseguito il codice che fornisce un'interfaccia utente migliore. Gli utenti non devono sapere come l'applicazione fornisce loro i dati; tutto ciò di cui hanno bisogno è accedervi.
Ad esempio, uno sviluppatore di app può includere controlli di accesso, come autorizzazioni di lettura o scrittura, nella capacità di un'applicazione di recuperare i dati. Se l'utente richiede informazioni nell'app, fornisce solo i dati a cui è stato autorizzato ad accedere.
Ma se gli sviluppatori non riescono a stabilire limiti chiaramente definiti tra i dati e le azioni eseguite in vari aspetti dell'applicazione, l'applicazione soffre di una vulnerabilità di incapsulamento. Gli aggressori ne traggono vantaggio inviando una richiesta all'applicazione, sapendo che tale azione risulterebbe in un messaggio di errore. Questo messaggio di errore fornisce quindi informazioni sulla struttura dell'applicazione, aiutando più strategie di attacco come un DOS – Denial of Service.
Riferimenti a oggetti diretti non sicuri (IDOR)
Gli URL delle applicazioni Web sono in grado di esporre il modello o il formato utilizzato per indirizzare gli utenti a posizioni di archiviazione back-end. Ad esempio, un URL potrebbe mostrare il modello/il formato per un identificatore di record in un sistema di archiviazione come un file system o un database.
L'IDOR da solo potrebbe essere una preoccupazione a basso rischio. Tuttavia, quando un IDOR viene combinato con un controllo del controllo degli accessi fallito, gli aggressori hanno la possibilità di colpire con successo.
Altre vulnerabilità comuni delle applicazioni Web che dovresti conoscere sono:
Divisione della risposta HTTP
Questo è un tipo di attacco di iniezione CRLF. HTTP è il processo attraverso il quale i browser inviano le query e i server restituiscono le risposte. In questa vulnerabilità dell'applicazione Web, gli aggressori malintenzionati utilizzano le notazioni CR e LR per manipolare il modo in cui i browser e i server comunicano tra loro, il che fornisce una richiesta ma dice al server di "dividere" la risposta in varie parti. La divisione della risposta in due parti diverse consente all'attore malintenzionato di ottenere il controllo sulle informazioni fornite dal server in risposta all'altra parte della richiesta. Quando tali dati richiesti sono dati ID utente o informazioni sensibili, l'attore malintenzionato ha eseguito correttamente l'attacco.
Difetto di iniezione
Un difetto di iniezione consente una pletora di varie tecniche di attacco. Qualsiasi applicazione che consente agli utenti di aggiornare il comando della shell, la chiamata del sistema operativo o un database può subire un difetto di iniezione. Gli aggressori dannosi sfruttano i difetti di injection per alterare i comandi che si trasformano in azioni nuove e impreviste all'interno dell'applicazione. Sfruttando queste vulnerabilità, gli attori malintenzionati sono in grado di creare, aggiornare, leggere o persino eliminare i dati.
Vulnerabilità di digest dei messaggi non sicura
Questa è una vulnerabilità crittografica che limita l'efficacia della crittografia. Un message digest dovrebbe comprendere la funzione di hash crittografica. A differenza della crittografia, le funzioni hash non richiedono che il mittente e gli utenti utilizzino le chiavi.
Gli aggressori dannosi sfruttano quindi le vulnerabilità digest insicure per perpetuare "attacchi di collisioni hash". L'obiettivo dell'attacco è scoprire se l'invio di un input porta alla generazione di un hash duplicativo. Se l'azione dannosa genera forzatamente un hash condiviso, possono utilizzare questo hash per presentare un file maligno per il download. Questo a sua volta lascia all'utente finale il presupposto che il file sia legittimo.
Protezione insufficiente dello strato di trasporto
La sicurezza del livello di trasporto (TLS) si riferisce al processo attraverso il quale le applicazioni del computer sono in grado di "comunicare" in modo sicuro tra loro su Internet. Un certo numero di applicazioni utilizza TLS solo durante il processo di autenticazione, che lascia i dati e le informazioni sulla sessione ID vulnerabili quando una persona utilizza l'applicazione.
Gli aggressori possono sfruttare questa vulnerabilità per deviare i dati mentre si spostano su Internet tra il dispositivo dell'utente e il server delle applicazioni.
Esecuzione di codice a distanza (RCE)
Le vulnerabilità dell'esecuzione di codice in modalità remota sono errori di codifica nelle applicazioni Web che consentono a malintenzionati di inserire codice indipendentemente dalla loro posizione geografica. Gli RCE rientrano in una categoria più ampia di vulnerabilità di iniezione di applicazioni Web in cui gli aggressori inseriscono il proprio codice in un'applicazione che non confermerà gli input dell'utente, facendo in modo che il server lo veda come codice dell'applicazione autentico. In genere, gli aggressori dannosi traggono vantaggio dalle vulnerabilità comunemente note senza patch e inseriscono il proprio codice nell'applicazione.
Inclusione remota di file (RFI)
Per collegare directory comuni a un'applicazione, gli sviluppatori aggiungono le istruzioni "include" nel loro codice. Ad esempio, un'applicazione potrebbe dover estrarre dati da un database. Invece di codificarlo manualmente per ottenere ogni file, l'istruzione "include" aiuta a collegare l'intera directory di origine in modo che tutto ciò che è memorizzato possa essere utilizzato.
Quando un'applicazione Web subisce una vulnerabilità RFI, gli aggressori possono manipolare l'applicazione per caricare codice dannoso o malware nel database, nel server o nel sito Web.
Errata configurazione della sicurezza
La probabilità di una configurazione errata della sicurezza è infatti una delle vulnerabilità delle applicazioni Web più comuni oggi. Questa vulnerabilità si verifica generalmente a causa della mancata modifica delle impostazioni di sicurezza predefinite da parte di un'organizzazione. Le comuni configurazioni errate di sicurezza sono:
- Utilizzo di password o account predefiniti
- Software senza patch
- Nessuna crittografia
- Politiche firewall inadeguate
- Trascurando risorse, funzionalità e altri componenti inutilizzati
SQL Injection
SQL, che significa Structured Query Language, è un linguaggio di programmazione utilizzato per i database. Consente il recupero e la manipolazione dei dati per i database relazionali. Una vulnerabilità SQL injection si trova in un gruppo più ampio di input utente non verificati. Quando gli attori malintenzionati inviano deliberatamente false richieste, l'applicazione Web risponde con un messaggio di errore che fornisce loro informazioni sulla struttura e sulla protezione del database.
Attivazione libreria automatica non convalidata
Per risparmiare tempo durante la codifica, gli sviluppatori tendono a utilizzare librerie di terze parti. Nella maggior parte dei casi, ciò consente loro di utilizzare codice pre-testato che accelera il processo di sviluppo dell'applicazione. L'utilizzo di codice open source pubblicamente disponibile, tuttavia, aumenta i rischi per la sicurezza, tra cui:
- L'assenza di proprietà documentata aumenta il rischio di aggiunta di codice maligno
- Progetti trascurati che non vengono più aggiornati
Questa particolare vulnerabilità è sempre più diffusa, considerando che diverse applicazioni coinvolgono dipendenze di librerie di terze parti.
Ci auguriamo che i contenuti di questo post sul blog siano stati davvero utili e perspicaci per te. Assicurarti di trovare una soluzione a qualsiasi vulnerabilità dell'applicazione web si applichi al tuo caso cambierà il gioco nelle esperienze dei tuoi dipendenti e clienti.