9 tipi di attacchi di tipo Web Application Injection più diffusi

Il problema con le applicazioni Web è che sono apertamente esposte a miliardi di utenti di Internet, molti dei quali vorranno violare le sue misure di sicurezza, per qualsiasi motivo.

Agli albori di Internet, uno dei metodi di attacco più comuni era la semplice forza bruta. I bot di solito eseguivano questi attacchi, o persone con un sacco di tempo libero, che provavano milioni di combinazioni di nomi utente e password fino a quando non ne trovavano una che garantisse l’accesso all’applicazione di destinazione.

Gli attacchi di forza bruta non sono più una minaccia, grazie alle politiche sulle password, ai tentativi di accesso limitati e ai captcha. Ma i criminali informatici amano scoprire nuovi exploit e usarli per eseguire nuovi tipi di attacchi. Molto tempo fa, hanno scoperto che i campi di testo nelle applicazioni o nelle pagine Web potevano essere sfruttati inserendo, o iniettando, testo inaspettato al loro interno che costringerebbe l’applicazione a fare qualcosa che non dovrebbe fare. In questo modo sono entrati in scena i cosiddetti attacchi con iniezione.

Gli attacchi di iniezione possono essere utilizzati non solo per accedere a un’applicazione senza conoscere nome utente e password, ma anche per esporre informazioni private, riservate o sensibili o persino per dirottare un intero server. Ecco perché questi attacchi non sono solo una minaccia per le applicazioni web, ma anche per gli utenti i cui dati risiedono su tali applicazioni e, nei casi peggiori, per altre applicazioni e servizi collegati.

Iniezione di codice

L’iniezione di codice è uno dei tipi più comuni di attacchi di iniezione. Se gli aggressori conoscono il linguaggio di programmazione, il framework, il database o il sistema operativo utilizzato da un’applicazione web, possono iniettare codice tramite campi di input di testo per costringere il server web a fare ciò che vogliono.

Questi tipi di attacchi injection sono possibili su applicazioni prive di convalida dei dati di input. Se un campo di input di testo consente agli utenti di inserire ciò che vogliono, l’applicazione è potenzialmente sfruttabile. Per prevenire questi attacchi, l’applicazione deve limitare il più possibile l’accesso degli utenti all’input.

Ad esempio, deve limitare la quantità di dati previsti, verificare il formato dei dati prima di accettarli e limitare il set di caratteri consentiti.

Le vulnerabilità di code injection possono essere facilmente individuate, semplicemente testando l’input di testo di un’applicazione Web con diversi tipi di contenuto. Una volta trovate, le vulnerabilità sono moderatamente difficili da sfruttare. Ma quando un utente malintenzionato riesce a sfruttare una di queste vulnerabilità, l’impatto potrebbe includere la perdita di riservatezza, integrità, disponibilità o funzionalità dell’applicazione.

SQL Injection

In modo simile al code injection, questo attacco inserisce uno script SQL, il linguaggio utilizzato dalla maggior parte dei database per eseguire operazioni di query, in un campo di input di testo. Lo script viene inviato all’applicazione, che lo esegue direttamente sul proprio database. Di conseguenza, l’attaccante potrebbe passare attraverso una schermata di accesso o eseguire azioni più pericolose, come leggere dati sensibili direttamente dal database, modificare o distruggere i dati del database o eseguire operazioni di amministrazione sul database.

Le applicazioni PHP e ASP sono soggette ad attacchi SQL injection a causa delle sue vecchie interfacce funzionali. Le app J2EE e ASP.Net sono in genere più protette da questi attacchi. Quando viene rilevata una vulnerabilità SQL injection, e potrebbe essere facilmente individuata, l’entità dei potenziali attacchi sarà limitata solo dall’abilità e dall’immaginazione dell’aggressore. Pertanto, l’impatto di un attacco SQL injection è indubbiamente elevato.

Iniezione di comandi

Anche questi attacchi sono possibili, principalmente a causa di un’insufficiente convalida dell’input. Differiscono dagli attacchi di code injection in quanto l’attaccante inserisce comandi di sistema invece di parti di codice o script di programmazione. Pertanto, l’hacker non ha bisogno di conoscere il linguaggio di programmazione in cui è basata l’applicazione o il linguaggio utilizzato dal database. Ma devono conoscere il sistema operativo utilizzato dal server di hosting.

I comandi di sistema inseriti vengono eseguiti dal sistema operativo host con i privilegi dell’applicazione, che potrebbe consentire di esporre il contenuto di file arbitrari che risiedono sul server, per mostrare la struttura delle directory di un server, per cambiare le password degli utenti, tra le altre cose .

Questi attacchi possono essere prevenuti da un amministratore di sistema, limitando il livello di accesso al sistema delle applicazioni Web in esecuzione su un server.

Cross Site Scripting

Ogni volta che un’applicazione inserisce l’input di un utente all’interno dell’output che genera, senza convalidarlo o codificarlo, offre a un utente malintenzionato l’opportunità di inviare codice dannoso a un altro utente finale. Gli attacchi Cross-Site Scripting (XSS) sfruttano queste opportunità per iniettare script dannosi in siti Web attendibili, che vengono infine inviati ad altri utenti dell’applicazione, che diventano le vittime dell’aggressore.

Il browser delle vittime eseguirà lo script dannoso senza sapere che non dovrebbe essere considerato attendibile. Pertanto, il browser gli consentirà di accedere a token di sessione, cookie o informazioni sensibili memorizzate dal browser. Se opportunamente programmati, gli script potrebbero persino riscrivere il contenuto di un file HTML.

Gli attacchi XSS possono essere generalmente suddivisi in due diverse categorie: archiviati e riflessi.

Negli attacchi XSS memorizzati, lo script dannoso risiede in modo permanente sul server di destinazione, in un forum di messaggi, in un database, in un registro dei visitatori, ecc. La vittima lo riceve quando il suo browser richiede le informazioni memorizzate. Negli attacchi XSS riflessi, lo script dannoso si riflette in una risposta che include l’input inviato al server. Questo potrebbe essere un messaggio di errore o un risultato di ricerca, per esempio.

Iniezione di XPath

Questo tipo di attacco è possibile quando un’applicazione Web utilizza le informazioni fornite da un utente per creare una query XPath per i dati XML. Il modo in cui funziona questo attacco è simile a SQL injection: gli aggressori inviano informazioni non corrette all’applicazione per scoprire come sono strutturati i dati XML, quindi attaccano nuovamente per accedere a tali dati.

XPath è un linguaggio standard con il quale, come SQL, puoi specificare gli attributi che vuoi trovare. Per eseguire una query sui dati XML, le applicazioni Web utilizzano l’input dell’utente per impostare un modello a cui i dati devono corrispondere. Inviando input non validi, il modello può trasformarsi in un’operazione che l’attaccante desidera applicare ai dati.

A differenza di quanto accade con SQL, in XPath non esistono versioni diverse. Ciò significa che l’iniezione di XPath può essere eseguita su qualsiasi applicazione Web che utilizza dati XML, indipendentemente dall’implementazione. Ciò significa anche che l’attacco può essere automatizzato; pertanto, a differenza di SQL injection, ha il potenziale per essere sparato contro un numero arbitrario di obiettivi.

Iniezione di comandi di posta

Questo metodo di attacco può essere utilizzato per sfruttare i server di posta elettronica e le applicazioni che creano istruzioni IMAP o SMTP con input utente convalidato in modo errato. Occasionalmente, i server IMAP e SMTP non dispongono di una forte protezione contro gli attacchi, come nel caso della maggior parte dei server Web, e pertanto potrebbero essere più sfruttabili. Entrando attraverso un server di posta, gli aggressori potrebbero eludere restrizioni come captcha, un numero limitato di richieste, ecc.

Per sfruttare un server SMTP, gli aggressori hanno bisogno di un account di posta elettronica valido per inviare messaggi con comandi iniettati. Se il server è vulnerabile, risponderà alle richieste degli aggressori, consentendo loro, ad esempio, di ignorare le restrizioni del server e utilizzare i suoi servizi per inviare spam.

L’IMAP injection potrebbe essere fatto principalmente su applicazioni webmail, sfruttando la funzionalità di lettura dei messaggi. In questi casi, l’attacco può essere eseguito semplicemente inserendo, nella barra degli indirizzi di un browser web, un URL con i comandi iniettati.

Iniezione CRLF

L’inserimento di caratteri di ritorno a capo e di avanzamento riga (combinazione nota come CRLF) nei campi di input del modulo web rappresenta un metodo di attacco chiamato CRLF injection. Questi caratteri invisibili indicano la fine di una riga o la fine di un comando in molti protocolli Internet tradizionali, come HTTP, MIME o NNTP.

Ad esempio, l’inserimento di un CRLF in una richiesta HTTP, seguito da un determinato codice HTML, potrebbe inviare pagine Web personalizzate ai visitatori di un sito Web.

Questo attacco può essere eseguito su applicazioni Web vulnerabili che non applicano il filtro appropriato all’input dell’utente. Questa vulnerabilità apre la porta ad altri tipi di attacchi injection, come XSS e code injection, e potrebbe anche derivare dal dirottamento di un sito web.

Iniezione di intestazione host

Nei server che ospitano molti siti Web o applicazioni Web, l’intestazione dell’host diventa necessaria per determinare quale dei siti Web o delle applicazioni Web residenti, ognuno dei quali è noto come host virtuale, deve elaborare una richiesta in arrivo. Il valore dell’intestazione indica al server a quale degli host virtuali inviare una richiesta. Quando il server riceve un’intestazione host non valida, di solito la passa al primo host virtuale nell’elenco. Ciò costituisce una vulnerabilità che gli aggressori possono utilizzare per inviare intestazioni host arbitrarie al primo host virtuale in un server.

La manipolazione dell’intestazione host è comunemente correlata alle applicazioni PHP, sebbene possa essere eseguita anche con altre tecnologie di sviluppo web. Gli attacchi di intestazione host funzionano come abilitatori per altri tipi di attacchi, come l’avvelenamento della cache web. Le sue conseguenze potrebbero includere l’esecuzione di operazioni sensibili da parte degli aggressori, ad esempio la reimpostazione della password.

Iniezione LDAP

LDAP è un protocollo progettato per facilitare la ricerca di risorse (dispositivi, file, altri utenti) in una rete. È molto utile per le intranet e, se utilizzato come parte di un sistema di single sign-on, può essere utilizzato per memorizzare nomi utente e password. Le query LDAP comportano l’uso di caratteri di controllo speciali che ne influenzano il controllo. Gli aggressori possono potenzialmente modificare il comportamento previsto di una query LDAP se possono inserire caratteri di controllo in essa.

Ancora una volta, il problema principale che consente gli attacchi di iniezione LDAP è l’input dell’utente convalidato in modo errato. Se il testo che un utente invia a un’applicazione viene utilizzato come parte di una query LDAP senza disinfettarlo, la query potrebbe finire per recuperare un elenco di tutti gli utenti e mostrarlo a un utente malintenzionato, semplicemente utilizzando un asterisco

nel posto giusto all’interno di una stringa di input.

Prevenzione degli attacchi di iniezione

Come abbiamo visto in questo articolo, tutti gli attacchi injection sono diretti verso server e applicazioni con accesso aperto a qualsiasi utente di Internet. La responsabilità di prevenire questi attacchi è distribuita tra gli sviluppatori di applicazioni e gli amministratori del server.