2.1 CVE-2011-4132

Questo schema di attacco comporta la causa di un buffer overflow attraverso la manipolazione delle variabili d'ambiente. Una volta che l'avversario scopre che può modificare una variabile d'ambiente, può cercare di far traboccare i buffer associati. Questo attacco sfrutta la fiducia implicita spesso riposta nelle variabili d'ambiente. [Identificare l'applicazione bersaglio] L'avversario identifica un'applicazione o un programma bersaglio su cui eseguire l'overflow del buffer. In questo attacco l'avversario cerca un'applicazione che carichi il contenuto di una variabile d'ambiente in un buffer. [Trovare il vettore di iniezione] L'avversario identifica un vettore di iniezione per fornire il contenuto eccessivo al buffer dell'applicazione bersaglio. [Creare il contenuto dell'overflow] L'avversario crea il contenuto da iniettare. Se l'intento è semplicemente quello di causare il crash del software, il contenuto deve solo consistere in una quantità eccessiva di dati casuali. Se l'intento è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario, l'avversario crea il payload in modo tale che l'indirizzo di ritorno sovrascritto venga sostituito con uno a scelta dell'avversario. [Utilizzando il vettore di iniezione, l'avversario inietta il contenuto di overflow artigianale nel buffer.

Un utente malintenzionato può usare l'iniezione SSI (Server Side Include) per inviare codice a un'applicazione web che poi viene eseguito dal server web. In questo modo l'attaccante può ottenere risultati simili al Cross Site Scripting, cioè l'esecuzione di codice arbitrario e la divulgazione di informazioni, anche se su una scala più limitata, poiché le direttive SSI non sono neanche lontanamente potenti come un linguaggio di scripting completo. Tuttavia, l'attaccante può comodamente ottenere l'accesso a file sensibili, come i file delle password, ed eseguire comandi di shell. [Determinare l'applicabilità] L'avversario determina se gli include lato server sono abilitati sul server web di destinazione. [Trovare il punto di iniezione] Cerca l'input controllabile dall'utente, comprese le intestazioni HTTP, che possono portare le direttive include lato server al server web. [Iniettare SSI] Utilizzando il punto di iniezione trovato, l'avversario invia codice arbitrario da includere nell'applicazione sul lato server. Potrebbe quindi aver bisogno di visualizzare una particolare pagina per far sì che il server esegua la direttiva include ed esegua un comando o apra un file per conto dell'avversario.

Un attaccante è in grado di indurre una vittima a caricare contenuti nel suo browser web che bypassa i controlli della zona di sicurezza e ottenere l'accesso a privilegi maggiori per eseguire codice di scripting o altri oggetti web come controlli ActiveX non firmati o applet. Questo è un attacco di elevazione dei privilegi mirato alla sicurezza del browser web basato su zone. [Trovare sistemi suscettibili all'attacco] Trovare sistemi che contengono funzionalità a cui si accede sia dalla zona internet che dalla zona locale. Ci deve essere un modo per fornire input a quella funzionalità dalla zona internet e quell'input originale deve essere usato in seguito su una pagina da una zona locale. [Trovare il punto di inserimento del carico utile] L'attaccante deve prima trovare qualche funzionalità del sistema o forse un'altra debolezza nel sistema (ad esempio la suscettibilità al cross site scripting) che fornirebbe all'attaccante un meccanismo per consegnare il carico utile (cioè il codice da eseguire) all'utente. La posizione da cui questo codice viene eseguito nel browser dell'utente deve essere all'interno della zona della macchina locale. [Sviluppare il payload da eseguire nella zona privilegiata superiore del browser dell'utente. Iniettare il carico utile e tentare di attirare la vittima (se possibile) nell'esecuzione della funzionalità che libera il carico utile.

Un attaccante usa metodi standard di iniezione SQL per iniettare dati nella linea di comando per l'esecuzione. Questo potrebbe essere fatto direttamente attraverso l'uso improprio di direttive come MSSQL_xp_cmdshell o indirettamente attraverso l'iniezione di dati nel database che verrebbero interpretati come comandi di shell. Qualche tempo dopo, un'applicazione backend senza scrupoli (o potrebbe essere parte della funzionalità della stessa applicazione) recupera i dati iniettati memorizzati nel database e utilizza questi dati come argomenti della riga di comando senza eseguire un'adeguata convalida. I dati malevoli sfuggono al piano dati generando nuovi comandi da eseguire sull'host. [Sonda per vulnerabilità SQL Injection] L'attaccante inietta la sintassi SQL negli input di dati controllabili dall'utente per cercare l'esecuzione non filtrata della sintassi SQL in una query. [Ottenere l'esecuzione di comandi arbitrari tramite SQL Injection con la direttiva MSSQL_xp_cmdshell] L'attaccante sfrutta un attacco SQL Injection per iniettare codice shell da eseguire sfruttando la direttiva xp_cmdshell. [Inject malicious data in the database] Sfrutta l'iniezione SQL per iniettare dati nel database che potrebbero poi essere utilizzati per ottenere l'iniezione di comandi se mai usati come argomento della riga di comando [Trigger command line execution with injected arguments] L'attaccante provoca l'esecuzione di funzionalità della riga di comando che sfrutta il contenuto del database precedentemente iniettato come argomento.

Un attaccante sfrutta una debolezza presente nel codice del livello di accesso al database generato con uno strumento di Object Relational Mapping (ORM) o una debolezza nel modo in cui uno sviluppatore ha usato un framework di persistenza per iniettare i propri comandi SQL da eseguire contro il database sottostante. L'attacco qui è simile alla semplice SQL injection, eccetto che l'applicazione non usa JDBC per parlare direttamente con il database, ma invece usa uno strato di accesso ai dati generato da uno strumento o framework ORM (ad esempio Hibernate). Mentre la maggior parte delle volte il codice generato da uno strumento ORM contiene metodi di accesso sicuri che sono immuni da SQL injection, a volte o a causa di qualche debolezza nel codice generato o a causa del fatto che lo sviluppatore non ha usato correttamente i metodi di accesso generati, SQL injection è ancora possibile. Un attaccante cerca di determinare quale framework di persistenza è usato dall'applicazione al fine di sfruttare una debolezza nel codice del livello di accesso ai dati generato o una debolezza nel modo in cui il livello di accesso ai dati può essere stato usato dallo sviluppatore. [Probe for ORM Injection vulnerabilities] L'attaccante inietta la sintassi ORM negli input di dati controllabili dall'utente dell'applicazione per determinare se è possibile modificare la struttura e il contenuto delle query di dati. [Perform SQL Injection through the generated data access layer] Un attaccante procede a sfruttare una debolezza nei metodi di accesso ai dati generati che non separa correttamente il piano di controllo dal piano dei dati, o potenzialmente un modo particolare in cui lo sviluppatore potrebbe aver usato male il codice generato, per modificare la struttura delle query SQL eseguite e/o iniettare query SQL completamente nuove.

Un aggressore modifica i parametri del messaggio SOAP che viene inviato dal consumatore di servizi al fornitore di servizi per avviare un attacco SQL injection. Dal lato del fornitore di servizi, il messaggio SOAP viene analizzato e i parametri non vengono adeguatamente convalidati prima di essere utilizzati per accedere a un database in un modo che non utilizza il binding dei parametri, permettendo così all'attaccante di controllare la struttura della query SQL eseguita. Questo schema descrive un attacco SQL injection con il meccanismo di consegna di un messaggio SOAP. [Detect Incorrect SOAP Parameter Handling] L'attaccante manomette i parametri del messaggio SOAP e cerca indicazioni che la manomissione abbia causato un cambiamento nel comportamento dell'applicazione presa di mira. [Probe for SQL Injection vulnerability] L'attaccante inietta la sintassi SQL nei parametri SOAP vulnerabili identificati durante la fase Explore per cercare l'esecuzione non filtrata della sintassi SQL in una query. [Inject SQL via SOAP Parameters] L'attaccante inietta SQL attraverso i parametri SOAP identificati come vulnerabili durante la fase Explore per lanciare un attacco SQL injection di primo o secondo ordine.

L'avversario utilizza una ripetizione del processo di codifica di un insieme di caratteri (cioè la codifica di un carattere di un carattere) per offuscare il carico utile di una particolare richiesta. Questo può permettere all'avversario di bypassare i filtri che tentano di rilevare caratteri o stringhe illegali, come quelli che potrebbero essere usati in attacchi di tipo traversal o injection. I filtri possono essere in grado di catturare stringhe codificate illegalmente, ma non possono catturare stringhe doppiamente codificate. Per esempio, un punto (.), spesso usato in attacchi di path traversal e quindi spesso bloccato dai filtri, potrebbe essere URL codificato come %2E. Tuttavia, molti filtri riconoscono questa codifica e bloccherebbero comunque la richiesta. In una doppia codifica, il % nella codifica URL di cui sopra verrebbe codificato di nuovo come %25, risultando in %252E che alcuni filtri potrebbero non cogliere, ma che potrebbe ancora essere interpretato come un punto (.) dagli interpreti sulla destinazione. [Sondare l'applicazione per gli input controllabili dall'utente] Usando un browser, uno strumento automatizzato o ispezionando l'applicazione, un attaccante registra tutti i punti di ingresso all'applicazione. [Sonda i punti d'ingresso per individuare le vulnerabilità] Prova la doppia codifica per parti dell'input per cercare di superare i filtri. Per esempio, con la doppia codifica di alcuni caratteri nell'URL (ad esempio punti e barre) un avversario può cercare di ottenere l'accesso a risorse limitate sul server web o forzare la navigazione verso pagine protette (sovvertendo così il servizio di autorizzazione). Un avversario può anche tentare altri attacchi di tipo injection utilizzando questo modello di attacco: command injection, SQL injection, ecc.

L'avversario modifica direttamente o indirettamente le variabili d'ambiente utilizzate dal software bersaglio o che lo controllano. L'obiettivo dell'avversario è quello di indurre il software di destinazione a deviare dal suo funzionamento previsto in un modo che avvantaggi l'avversario. [Sonda dell'applicazione bersaglio] L'avversario prima sonda l'applicazione bersaglio per determinare informazioni importanti sul bersaglio. Queste informazioni potrebbero includere i tipi di software usati, le versioni del software, quali input dell'utente consuma l'applicazione e così via. Ancora più importante, l'avversario cerca di determinare quali variabili d'ambiente potrebbero essere utilizzate dal software sottostante, o anche dall'applicazione stessa. [Usando le informazioni trovate sondando l'applicazione, l'avversario cerca di manipolare qualsiasi variabile d'ambiente controllata dall'utente che ha scoperto essere usata dall'applicazione, o che sospetta essere usata dall'applicazione, e osserva gli effetti di questi cambiamenti. Se l'avversario nota dei cambiamenti significativi nell'applicazione, saprà che una certa variabile d'ambiente è importante per il comportamento dell'applicazione e indica un possibile vettore di attacco. [Manipolare le variabili d'ambiente controllate dall'utente] L'avversario manipola la variabile o le variabili d'ambiente trovate per abusare del normale flusso dei processi o per ottenere l'accesso a risorse privilegiate.

Un avversario include caratteri di formattazione in un campo di input di stringa nell'applicazione di destinazione. La maggior parte delle applicazioni presuppone che gli utenti forniscano un testo statico e possono rispondere in modo imprevedibile alla presenza del carattere di formattazione. Per esempio, in alcune funzioni dei linguaggi di programmazione C come printf, il carattere di formattazione %s stamperà il contenuto di una locazione di memoria aspettandosi che questa locazione identifichi una stringa e il carattere di formattazione %n stampa il numero di DWORD scritti nella memoria. Un avversario può usarlo per leggere o scrivere in posizioni di memoria o file, o semplicemente per manipolare il valore del testo risultante in modi inaspettati. La lettura o la scrittura della memoria può provocare crash del programma e la scrittura della memoria potrebbe provocare l'esecuzione di codice arbitrario se l'avversario può scrivere sullo stack del programma. L'avversario fa un inventario dei punti di ingresso dell'applicazione. [Determinare l'input controllabile dall'utente suscettibile di iniezione di stringhe di formato] Determina l'input controllabile dall'utente suscettibile di iniezione di stringhe di formato. Per ogni input controllabile dall'utente che l'avversario sospetta sia vulnerabile all'iniezione di stringhe di formato, tenta di iniettare caratteri di formattazione come %n, %s, ecc. L'obiettivo è quello di manipolare la creazione della stringa utilizzando questi caratteri di formattazione. Dopo aver determinato che un dato input è vulnerabile all'iniezione di stringhe di formato, ipotizzare quale sia l'uso sottostante e i vincoli associati.

Un attaccante manipola o crea una query LDAP allo scopo di minare la sicurezza dell'obiettivo. Alcune applicazioni usano l'input dell'utente per creare query LDAP che vengono elaborate da un server LDAP. Per esempio, un utente potrebbe fornire il proprio nome utente durante l'autenticazione e il nome utente potrebbe essere inserito in una query LDAP durante il processo di autenticazione. Un aggressore potrebbe usare questo input per iniettare comandi aggiuntivi in una query LDAP che potrebbe rivelare informazioni sensibili. Per esempio, inserendo un * nella suddetta query potrebbe restituire informazioni su tutti gli utenti del sistema. Questo attacco è molto simile ad un attacco SQL injection in quanto manipola una query per raccogliere informazioni aggiuntive o costringere un particolare valore di ritorno. [L'attaccante fa un inventario dei punti di ingresso dell'applicazione. [Determinare l'input controllabile dall'utente suscettibile di iniezione LDAP] Per ogni input controllabile dall'utente che l'attaccante sospetta sia vulnerabile all'iniezione LDAP, tenta di iniettare i caratteri che hanno un significato speciale in LDAP (come un singolo carattere di virgolette, ecc.). L'obiettivo è quello di creare una query LDAP con una sintassi non valida [Cercare di sfruttare la vulnerabilità dell'iniezione LDAP] Dopo aver determinato che un dato input è vulnerabile all'iniezione LDAP, ipotizzare l'aspetto della query sottostante. Possibilmente utilizzando uno strumento, provare iterativamente ad aggiungere la logica alla query per estrarre informazioni dal LDAP, o per modificare o cancellare informazioni nel LDAP.

Questo tipo di attacco sfrutta una vulnerabilità di buffer overflow nel software client mirato attraverso l'iniezione di contenuti dannosi da un servizio ostile personalizzato. Questo servizio ostile è creato per fornire il contenuto corretto al software client. Per esempio, se l'applicazione lato client è un browser, il servizio ospiterà una pagina web che il browser carica. [L'avversario identifica un'applicazione client-side di destinazione su cui eseguire il buffer overflow. I più comuni sono i browser. Se c'è una nota vulnerabilità del browser, un avversario potrebbe prendere di mira quella. [Trovare il vettore di iniezione] L'avversario identifica un vettore di iniezione per fornire il contenuto eccessivo al buffer dell'applicazione bersaglio. [Creare un servizio ostile] L'avversario crea un servizio ostile che consegnerà il contenuto all'applicazione lato client. Se l'intento è semplicemente quello di causare il crash del software, il contenuto deve solo consistere in una quantità eccessiva di dati casuali. Se l'intento è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario, l'avversario crea il payload in modo tale che l'indirizzo di ritorno sovrascritto venga sostituito con uno a scelta dell'avversario. [Utilizzando il vettore di iniezione, l'avversario consegna il contenuto all'applicazione lato client che utilizza il servizio ostile e fa traboccare il buffer.

Un attaccante sfrutta una debolezza nella validazione dell'input controllando il formato, la struttura e la composizione dei dati ad un'interfaccia di elaborazione dell'input. Fornendo un input di forma non standard o inaspettata, un attaccante può avere un impatto negativo sulla sicurezza dell'obiettivo.

Un attaccante inganna una vittima per eseguire contenuti flash dannosi che eseguono comandi o fanno chiamate flash specificate dall'attaccante. Un esempio di questo attacco è il cross-site flashing, un parametro controllato dall'attaccante per una chiamata di riferimento viene caricato dal contenuto specificato dall'attaccante. [L'attaccante prima fa un inventario dei punti di ingresso dell'applicazione. [Determinare la suscettibilità dell'applicazione all'iniezione di Flash] Determina la suscettibilità dell'applicazione all'iniezione di Flash. Per ogni URL identificato nella fase di esplorazione, l'attaccante tenta di utilizzare varie tecniche come il caricamento diretto come funzione, la pagina/host malvagia controllata, l'iniezione Flash HTML e l'iniezione DOM per determinare se l'applicazione è suscettibile di iniezione Flash. [Iniettare contenuti dannosi nell'obiettivo] Iniettare contenuti dannosi nell'obiettivo utilizzando i vettori di iniezione vulnerabili identificati nella fase Experiment

Un avversario crea un file con contenuto di scripting ma dove il tipo MIME specificato del file è tale che lo scripting non è previsto. L'avversario inganna la vittima facendole accedere ad un URL che risponde con il file di script. Alcuni browser rileveranno che il tipo MIME specificato del file non corrisponde al tipo reale del suo contenuto e passeranno automaticamente a utilizzare un interprete per il tipo di contenuto reale. Se il browser non invoca i filtri per gli script prima di fare questo, lo script dell'avversario può essere eseguito sul bersaglio non sterilizzato, possibilmente rivelando i cookie della vittima o eseguendo script arbitrari nel suo browser. [Utilizzando un browser o uno strumento automatizzato, un avversario segue tutti i link pubblici e le azioni su un sito web. Registrano tutte le aree che permettono ad un utente di caricare contenuti attraverso una richiesta HTTP POST. Questo si trova tipicamente nei blog o nei forum. [L'avversario utilizza i punti di ingresso raccolti nella fase "Explore" come una lista di obiettivi e carica file con contenuti di scripting, ma il cui tipo MIME è specificato come un tipo di file che non può eseguire contenuti di scripting. Se l'applicazione controlla solo il tipo MIME del file, potrebbe lasciar passare il file, causando l'esecuzione dello script da qualsiasi utente che accede al file. [Una volta che l'avversario ha determinato quali luoghi di caricamento dei file sono vulnerabili al mismatch del tipo MIME, caricherà uno script dannoso camuffato da un file non scripting. L'avversario può avere molti obiettivi, dal rubare ID di sessione, cookie, credenziali e contenuti di pagina da una vittima. [Affinché l'attacco abbia successo, la vittima deve visualizzare il contenuto dannoso memorizzato sulla pagina web.

Un attacco di questo tipo sfrutta le vulnerabilità nell'autenticazione del canale di comunicazione client/server e nell'integrità dei dati. Sfrutta la fiducia implicita che un server ripone nel client o, cosa più importante, ciò che il server crede sia il client. Un utente malintenzionato esegue questo tipo di attacco comunicando direttamente con il server in cui il server crede di comunicare solo con un client valido. Esistono numerose varianti di questo tipo di attacco.

Un avversario avvelena i file con un payload malevolo (mirando ai file system accessibili dal software di destinazione), che può essere passato attraverso canali standard come via e-mail, e contenuti web standard come PDF e file multimediali. L'avversario sfrutta vulnerabilità note o routine di gestione nei processi di destinazione, al fine di sfruttare la fiducia dell'host nell'esecuzione di contenuti remoti, compresi i file binari.

Le applicazioni spesso hanno bisogno di trasformare i dati dentro e fuori un formato di dati (ad esempio, XML e YAML) utilizzando un parser. Può essere possibile per un avversario iniettare dati che possono avere un effetto negativo sul parser durante l'elaborazione. Molti linguaggi di formato dati permettono la definizione di strutture simili a macro che possono essere utilizzate per semplificare la creazione di strutture complesse. Annidando queste strutture, facendo sì che i dati vengano sostituiti ripetutamente, un avversario può far sì che il parser consumi più risorse durante l'elaborazione, causando un consumo eccessivo di memoria e un utilizzo eccessivo della CPU. Un avversario determina il flusso di dati in ingresso che viene elaborato da un parser di dati che supporta l'uso della sostituzione da parte della vittima. Un avversario crea dati di input che possono avere un effetto negativo sul funzionamento del parser quando i dati vengono analizzati sul sistema della vittima.

Un avversario inietta payload di dati serializzati sovradimensionati in un parser durante l'elaborazione dei dati per produrre effetti negativi sul parser, come l'esaurimento delle risorse di sistema e l'esecuzione di codice arbitrario. Un avversario determina il flusso di dati di ingresso che viene elaborato da un parser di dati serializzati sul lato della vittima. Un avversario crea dati di input che possono avere un effetto negativo sul funzionamento del parser di dati quando questi vengono analizzati sul sistema della vittima.

In questo attacco, l'idea è di far fallire un filtro attivo causando una transazione sovradimensionata. Un attaccante può cercare di inserire stringhe di input troppo lunghe nel programma nel tentativo di sopraffare il filtro (causando un buffer overflow) e sperando che il filtro non fallisca in modo sicuro (cioè l'input dell'utente viene lasciato nel sistema non filtrato). [Sondaggio] L'attaccante esamina l'applicazione di destinazione, possibilmente come un utente valido e autenticato [Tentativi di iniezioni] Cerca di inserire dati troppo lunghi nel sistema. Questo può essere fatto manualmente o uno strumento dinamico (scatola nera) può essere usato per automatizzare questo. Un attaccante può anche usare uno script personalizzato per questo scopo. [Monitorare le risposte] Osservare qualsiasi indicazione di fallimento che si verifica. Guarda attentamente per vedere cosa è successo quando si è verificato il fallimento del filtro. I dati sono entrati? [Abusare del sistema attraverso il fallimento del filtro] Un attaccante scrive uno script per indurre costantemente il fallimento del filtro.

Un aggressore utilizza l'input XML controllato dall'utente per sondare, attaccare e iniettare dati nel database XML, utilizzando tecniche simili all'iniezione SQL. L'input controllabile dall'utente può permettere la visualizzazione non autorizzata dei dati, bypassando l'autenticazione o l'applicazione front-end per l'accesso diretto al database XML, e possibilmente alterando le informazioni del database. [Survey the Target] Utilizzando un browser o uno strumento automatizzato, un avversario registra tutte le istanze di input controllabili dall'utente utilizzate per costruire le query XML [Determine the Structure of Queries] Utilizzando mezzi manuali o automatizzati, testa gli input trovati per le debolezze XML. [Inject Content into XML Queries] Realizza un contenuto malevolo contenente espressioni XML che non viene convalidato dall'applicazione e viene eseguito come parte delle query XML.

Un avversario che è autorizzato a inviare query a un bersaglio invia varianti delle query attese nella speranza che queste query modificate possano restituire informazioni (direttamente o indirettamente attraverso i log degli errori) oltre a ciò che l'insieme di query attese dovrebbe fornire. [Observe communication and inputs] L'avversario del fuzzing osserva il sistema target alla ricerca di input e comunicazioni tra moduli, sottosistemi o sistemi. [Generare input fuzzed] Dato uno strumento di fuzzing, un input o un protocollo target, e limiti di tempo, complessità e varietà di input, genera una lista di input da provare. Sebbene il fuzzing sia casuale, non è esaustivo. Parametri come la lunghezza, la composizione e quante variazioni provare sono importanti per ottenere l'impatto più conveniente dal fuzzer. [Osservare il risultato] Osservare gli output degli input immessi nel sistema dai fuzzer e vedere se ci sono messaggi di log o di errore che forniscono dati sensibili all'utente o danno informazioni su un modello atteso che potrebbe essere usato per produrre questi dati. [Se i log non hanno rivelato alcun dato sensibile per l'utente, un avversario tenterà di far sì che gli input del fuzzer si conformino ad un modello atteso.

Un avversario sfrutta la possibilità di codificare input o contenuti potenzialmente dannosi utilizzati dalle applicazioni in modo tale che le applicazioni siano inefficaci nel validare questo standard di codifica. [Indagare l'applicazione per gli input controllabili dall'utente] Utilizzando un browser, uno strumento automatizzato o ispezionando l'applicazione, un avversario registra tutti i punti di ingresso all'applicazione. [Sonda i punti d'ingresso per individuare le vulnerabilità] L'avversario usa i punti d'ingresso raccolti nella fase "Esplora" come lista di obiettivi e inietta vari payloads usando una varietà di diversi tipi di codifica per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità con una logica di validazione insufficiente e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata.

In questo modello di attacco, l'avversario sfrutta il fuzzing per cercare di identificare le debolezze del sistema. Il fuzzing è un metodo di test di sicurezza e funzionalità del software che alimenta un input costruito a caso al sistema e cerca un'indicazione che si è verificato un errore in risposta a quell'input. Il fuzzing tratta il sistema come una scatola nera ed è totalmente libero da qualsiasi preconcetto o ipotesi sul sistema. Il fuzzing può aiutare un attaccante a scoprire certe assunzioni fatte sull'input dell'utente nel sistema. Il fuzzing dà ad un attaccante un modo veloce di scoprire potenzialmente alcune di queste assunzioni, nonostante non conosca necessariamente nulla dell'interno del sistema. Questi presupposti possono poi essere rivoltati contro il sistema creando un input utente speciale che può permettere all'attaccante di raggiungere i suoi obiettivi. [Osservare le comunicazioni e gli input] L'attaccante di fuzzing osserva il sistema target alla ricerca di input e comunicazioni tra moduli, sottosistemi o sistemi. [Generare input fuzzed] Dato uno strumento di fuzzing, un input o un protocollo target, e limiti di tempo, complessità e varietà di input, genera una lista di input da provare. Sebbene il fuzzing sia casuale, non è esaustivo. Parametri come la lunghezza, la composizione e quante variazioni provare sono importanti per ottenere l'impatto più conveniente dal fuzzer. Osservare il risultato] Osservare gli output agli input immessi nel sistema dai fuzzer e vedere se succede qualcosa di interessante. Se si verifica un fallimento, determinare perché è successo. Scoprire l'ipotesi di fondo che è stata invalidata dall'input. Mettere nel sistema un input appositamente creato che sfrutta la debolezza identificata attraverso il fuzzing e permette di raggiungere gli obiettivi dell'attaccante. I fuzzer spesso rivelano modi per sfuggire ai filtri di validazione dell'input e introdurre dati indesiderati nel sistema.

Alcune API rimuovono alcuni caratteri iniziali da una stringa di parametri. Un avversario può intenzionalmente introdurre caratteri "fantasma" iniziali (caratteri extra che non influenzano la validità della richiesta al livello API) che permettono all'input di passare i filtri e quindi elaborare l'input dell'avversario. Questo si verifica quando l'API mirata accetta dati di input in diverse forme sintattiche e li interpreta nel modo semantico equivalente, mentre il filtro non tiene conto dell'intero spettro delle forme sintattiche accettabili dall'API mirata. [Indagare l'applicazione per gli input controllabili dall'utente] Utilizzando un browser, uno strumento automatizzato o ispezionando l'applicazione, un avversario registra tutti i punti di ingresso all'applicazione. [Sonda i punti d'ingresso per individuare le vulnerabilità] L'avversario usa i punti d'ingresso raccolti nella fase "Esplora" come una lista di obiettivi e inietta varie sequenze di caratteri "fantasma" per determinare come l'applicazione li filtra. [Bypassare il filtraggio dell'input] Usando ciò che l'avversario ha imparato su come l'applicazione filtra i dati di input, crea specifici dati di input che bypassano il filtro. Questo può portare ad attacchi di attraversamento di directory, esecuzione di comandi shell arbitrari, corruzione di file, ecc.

Questo attacco si basa sull'uso dei cookie HTTP per memorizzare credenziali, informazioni di stato e altri dati critici sui sistemi client. Ci sono diverse forme di questo attacco. La prima forma di questo attacco comporta l'accesso ai cookie HTTP per estrarre i dati potenzialmente sensibili in essi contenuti. La seconda forma comporta l'intercettazione di questi dati mentre vengono trasmessi dal client al server. Queste informazioni intercettate sono poi utilizzate dall'avversario per impersonare l'utente/sessione remota. La terza forma è quando il contenuto del cookie viene modificato dall'avversario prima di essere rimandato al server. Qui l'avversario cerca di convincere il server di destinazione ad operare su queste informazioni falsificate. Ottenere una copia del cookie] L'avversario deve prima ottenere una copia del cookie. L'avversario può essere un utente finale legittimo che vuole aumentare i privilegi, o potrebbe essere qualcuno che sniffa su una rete per ottenere una copia dei cookie HTTP. [Ottenere informazioni sensibili dal cookie] L'avversario potrebbe essere in grado di ottenere informazioni sensibili dal cookie. Gli sviluppatori dell'applicazione web potrebbero aver dato per scontato che i cookie non siano accessibili agli utenti finali, e quindi, potrebbero averci messo informazioni potenzialmente sensibili. L'avversario potrebbe essere in grado di modificare o sostituire i cookie per aggirare i controlli di sicurezza dell'applicazione.

Un attaccante sfrutta una debolezza nella routine di conversione MIME per causare un buffer overflow e ottenere il controllo della macchina server di posta. Il sistema MIME è progettato per consentire l'interpretazione e l'invio via e-mail di diversi formati di informazioni. I punti di attacco esistono quando i dati vengono convertiti in formato MIME compatibile e viceversa. [Identificare il server di posta obiettivo] L'avversario identifica un server di posta obiettivo che desidera attaccare. [Determinare la fattibilità dell'attacco] Determinare se il server di posta è privo di patch ed è potenzialmente vulnerabile a uno dei noti buffer overflow di conversione MIME (ad esempio Sendmail 8.8.3 e 8.8.4). [Trovare il vettore di iniezione] Identificare i posti nel sistema dove le routine di conversione MIME vulnerabili possono essere usate. [L'avversario crea messaggi e-mail con intestazioni speciali che causeranno un buffer overflow per la routine di conversione MIME vulnerabile. L'intento di questo attacco è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario e ottenere l'accesso alla macchina del server di posta, quindi l'avversario creerà un'e-mail che non solo fa overflow del buffer mirato, ma lo fa in modo tale che l'indirizzo di ritorno sovrascritto sia sostituito con uno a scelta dell'avversario. [Inviare messaggi di posta elettronica al sistema di destinazione con intestazioni appositamente create che innescano l'overflow del buffer ed eseguono il codice della shell.

Un attaccante fornisce al software di destinazione dati di input che contengono sequenze di caratteri speciali progettati per bypassare la logica di validazione dell'input. Questo exploit si basa sul fatto che l'obiettivo fa più passaggi sui dati di input ed elabora un "livello" di caratteri speciali ad ogni passaggio. In questo modo, l'attaccante può mascherare l'input che altrimenti verrebbe rifiutato come non valido, nascondendolo con strati di caratteri speciali/escape che vengono rimossi dai successivi passaggi di elaborazione. L'obiettivo è quello di scoprire prima i casi in cui il livello di validazione dell'input viene eseguito prima di uno o più livelli di analisi. Cioè, l'input dell'utente può passare attraverso la seguente logica in un'applicazione: <parser1> --> <validatore di input> --> <parser2>. In questi casi, l'attaccante avrà bisogno di fornire un input che passerà attraverso il validatore di input, ma dopo essere passato attraverso il parser2, sarà convertito in qualcosa che il validatore di input avrebbe dovuto fermare. [L'attaccante deve prima determinare tutti gli input dell'applicazione/sistema in cui si vuole bypassare la validazione dell'input. [Determinare quali codifiche di caratteri sono accettate dall'applicazione/sistema] L'attaccante deve quindi fornire varie codifiche di caratteri all'applicazione/sistema e determinare quali sono accettate. L'attaccante dovrà osservare la risposta dell'applicazione/sistema ai dati codificati per determinare se i dati sono stati interpretati correttamente. [L'attaccante ora combina le codifiche accettate dall'applicazione. L'attaccante può combinare diverse codifiche o applicare la stessa codifica più volte. [L'attaccante sfrutta la sua capacità di bypassare la validazione dell'input per ottenere un accesso non autorizzato al sistema. Ci sono molti attacchi possibili, e alcuni esempi sono menzionati qui.

Questo tipo di attacco sfrutta l'uso di link simbolici per causare buffer overflow. Un avversario può cercare di creare o manipolare un file di collegamento simbolico in modo tale che il suo contenuto risulti in dati fuori dai limiti. Quando il software di destinazione elabora il file di collegamento simbolico, potrebbe potenzialmente far traboccare i buffer interni con un controllo insufficiente dei limiti. [Identificare l'applicazione di destinazione] L'avversario identifica un'applicazione o un programma di destinazione che potrebbe caricare determinati file in memoria. [Trovare il vettore di iniezione] L'avversario identifica un vettore di iniezione per fornire il contenuto eccessivo al buffer dell'applicazione bersaglio. [Creare il contenuto del file di overflow] L'avversario crea il contenuto da iniettare. Se l'intento è semplicemente quello di causare il crash del software, il contenuto deve solo consistere in una quantità eccessiva di dati casuali. Se l'intento è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario, l'avversario crea il payload in modo tale che l'indirizzo di ritorno sovrascritto venga sostituito con uno di sua scelta. [Utilizzando il contenuto del file appositamente creato, l'avversario crea un collegamento simbolico dalla risorsa identificata al file dannoso, causando un attacco mirato di overflow del buffer.

Questo tipo di attacco sfrutta l'uso di tag o variabili da dati di configurazione formattati per causare un buffer overflow. L'avversario crea una pagina HTML dannosa o un file di configurazione che include stringhe sovradimensionate, causando così un overflow. [L'avversario identifica un'applicazione o un programma di destinazione su cui eseguire l'overflow del buffer. Gli avversari cercano applicazioni o programmi che accettano file formattati, come i file di configurazione, come input. [Trovare il vettore di iniezione] L'avversario identifica un vettore di iniezione per fornire il contenuto eccessivo al buffer dell'applicazione bersaglio. [L'avversario crea il contenuto da iniettare. Se l'intento è semplicemente quello di causare il crash del software, il contenuto deve solo consistere in una quantità eccessiva di dati casuali. Se l'intento è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario, l'avversario crea il payload in modo tale che l'indirizzo di ritorno sovrascritto venga sostituito con uno a scelta dell'avversario. [L'avversario caricherà il file modificato nell'applicazione, causando un overflow del buffer.

In questo attacco, al software di destinazione viene dato un input che l'avversario sa che sarà modificato e ampliato nelle dimensioni durante l'elaborazione. Questo attacco si basa sul fatto che il software di destinazione non riesce ad anticipare che i dati espansi possono superare qualche limite interno, creando così un buffer overflow. [L'avversario identifica un'applicazione o un programma su cui eseguire il buffer overflow. Gli avversari spesso cercano applicazioni che accettano input dall'utente e che eseguono una gestione manuale della memoria. [Trovare il vettore di iniezione] L'avversario identifica un vettore di iniezione per fornire il contenuto eccessivo al buffer dell'applicazione bersaglio. [Creare il contenuto dell'overflow] L'avversario crea l'input da dare al programma. Se l'intento è semplicemente quello di causare il crash del software, l'input deve solo espandersi in una quantità eccessiva di dati casuali. Se l'intento è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario, l'avversario creerà un input che si espande in un modo che non solo fa traboccare il buffer mirato, ma lo fa in modo tale che l'indirizzo di ritorno sovrascritto viene sostituito con uno scelto dall'avversario che punta al codice iniettato dall'avversario. [Usando il vettore di iniezione, l'avversario dà l'input artigianale al programma, facendo traboccare il buffer.

Un utente malintenzionato genera un messaggio o un blocco dati che induce il destinatario a credere che il messaggio o il blocco dati sia stato generato e firmato crittograficamente da una fonte autorevole o attendibile, inducendo una vittima o un sistema operativo della vittima a eseguire azioni dannose.

Un avversario inserisce uno o più byte nulli nell'input del software di destinazione. Questo attacco si basa sull'uso di un byte a valore nullo come terminatore di stringa in molti ambienti. L'obiettivo è che alcuni componenti del software di destinazione interrompano l'elaborazione dell'input quando incontrano i byte nulli. [Utilizzando un browser, uno strumento automatico o ispezionando l'applicazione, un avversario registra tutti i punti di ingresso all'applicazione. [Sondare i punti d'ingresso per individuare le vulnerabilità] L'avversario usa i punti d'ingresso raccolti nella fase "Esplora" come una lista di obiettivi e inietta byte nulli postfix per osservare come l'applicazione li gestisce come input. L'avversario è alla ricerca di aree in cui l'input dell'utente è posto nel mezzo di una stringa, e il byte nullo fa sì che l'applicazione interrompa l'elaborazione della stringa alla fine dell'input dell'utente. [Dopo aver determinato i punti di ingresso che sono vulnerabili, l'avversario posiziona uno o più byte nulli in modo tale da rimuovere i dati dopo il byte nullo in un modo che è vantaggioso per loro.

Se una stringa viene passata attraverso un filtro di qualche tipo, allora un NULL terminale potrebbe non essere valido. L'uso di una rappresentazione alternativa del NULL permette ad un avversario di incorporare il NULL a metà della stringa mentre postfissa i dati corretti in modo da evitare il filtro. Un esempio è un filtro che cerca un carattere slash finale. Se l'inserimento della stringa è possibile, ma lo slash deve esistere, si può usare una codifica alternativa del NULL in mezzo alla stringa. [Sondare l'applicazione per gli input controllabili dall'utente] Usando un browser, uno strumento automatizzato o ispezionando l'applicazione, un avversario registra tutti i punti di ingresso all'applicazione. [Sonda i punti d'ingresso per individuare le vulnerabilità] L'avversario usa i punti d'ingresso raccolti nella fase "Esplora" come una lista di obiettivi e inietta i byte null postfix seguiti da un backslash per osservare come l'applicazione li gestisce come input. L'avversario è alla ricerca di aree in cui l'input dell'utente è posto nel mezzo di una stringa, e il byte nullo fa sì che l'applicazione interrompa l'elaborazione della stringa alla fine dell'input dell'utente. [Dopo aver determinato i punti di ingresso che sono vulnerabili, l'avversario inserisce un byte nullo seguito da un backslash in modo da bypassare un filtro di input e rimuovere i dati dopo il byte nullo in un modo che è vantaggioso per loro.

Questo tipo di attacco è una forma di Cross-Site Scripting (XSS) in cui uno script malevolo viene inserito nell'HTML lato client che viene analizzato da un browser web. Il contenuto servito da un'applicazione web vulnerabile include codice script utilizzato per manipolare il Document Object Model (DOM). Questo codice script o non convalida correttamente l'input, o non esegue una corretta codifica dell'output, creando così un'opportunità per un avversario di iniettare uno script dannoso e lanciare un attacco XSS. Una distinzione chiave tra gli altri attacchi XSS e gli attacchi basati su DOM è che negli altri attacchi XSS, lo script dannoso viene eseguito quando la pagina web vulnerabile viene inizialmente caricata, mentre un attacco basato su DOM viene eseguito dopo il caricamento della pagina. Un'altra distinzione degli attacchi basati su DOM è che in alcuni casi, lo script dannoso non viene mai inviato al server web vulnerabile. Un attacco come questo è garantito per bypassare qualsiasi tentativo di filtraggio lato server per proteggere gli utenti. [Utilizzando un browser o uno strumento automatizzato, un avversario segue tutti i collegamenti pubblici e le azioni su un sito web. Registra tutti i link, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. [L'avversario utilizza i punti d'ingresso raccolti nella fase "Explore" come una lista di obiettivi e inietta vari payloads di script comuni e caratteri speciali per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata. Specificamente per gli XSS basati su DOM, l'avversario cerca aree in cui l'input viene utilizzato per modificare direttamente il DOM. [Una volta che l'avversario ha determinato quali parametri sono vulnerabili agli XSS, creerà un URL dannoso contenente l'exploit XSS. L'avversario può avere molti obiettivi, dal rubare ID di sessione, cookie, credenziali e contenuti della pagina dalla vittima. Negli XSS basati sul DOM, lo script dannoso potrebbe anche non essere inviato al server, poiché il browser della vittima manipolerà il DOM stesso. Questo può aiutare ad evitare i meccanismi di rilevamento lato server. [Per far sì che l'attacco abbia successo, la vittima deve accedere all'URL dannoso.

Un avversario incorpora script dannosi nel contenuto che sarà servito ai browser web. L'obiettivo dell'attacco è che il software bersaglio, il browser lato client, esegua lo script con il livello di privilegio degli utenti. Un attacco di questo tipo sfrutta le vulnerabilità di un programma che vengono portate permettendo agli host remoti di eseguire codice e script. I browser web, per esempio, hanno alcuni semplici controlli di sicurezza, ma se un aggressore remoto è autorizzato a eseguire script (attraverso l'iniezione in contenuti generati dall'utente come le bacheche) allora questi controlli possono essere aggirati. Inoltre, questi attacchi sono molto difficili da rilevare per un utente finale. [Utilizzando un browser o uno strumento automatizzato, un attaccante segue tutti i collegamenti pubblici e le azioni su un sito web. Registra tutti i link, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. [Sonda i potenziali punti d'ingresso identificati per la vulnerabilità XSS] L'attaccante usa i punti d'ingresso raccolti nella fase "Esplora" come una lista di obiettivi e inietta vari payload di script comuni per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata. [Rubare ID di sessione, credenziali, contenuto della pagina, ecc.] Quando l'attaccante riesce a sfruttare la vulnerabilità, può scegliere di rubare le credenziali dell'utente per riutilizzarle o analizzarle in seguito. [Quando l'aggressore prende di mira l'applicazione corrente o un'altra (attraverso le vulnerabilità CSRF), sarà l'utente ad eseguire gli attacchi senza esserne consapevole. Questi attacchi sono per lo più rivolti alle falle della logica delle applicazioni, ma possono anche essere utilizzati per creare un attacco diffuso contro un particolare sito web sulla rete attuale dell'utente (Internet o meno). [Content spoofing] Manipolando il contenuto, l'attaccante prende di mira le informazioni che l'utente vorrebbe ottenere dal sito web.

Questo attacco prende di mira la codifica dell'URL combinata con la codifica dei caratteri slash. Un attaccante può approfittare dei molteplici modi di codificare un URL e abusare dell'interpretazione dell'URL. Un URL può contenere caratteri speciali che hanno bisogno di una gestione speciale della sintassi per essere interpretati. I caratteri speciali sono rappresentati utilizzando un carattere percentuale seguito da due cifre che rappresentano il codice ottetto del carattere originale (%HEX-CODE). Per esempio il carattere spazio US-ASCII sarebbe rappresentato con %20. Questo è spesso chiamato escape ending o percent-encoding. Poiché il server decodifica l'URL dalle richieste, può limitare l'accesso ad alcuni percorsi URL convalidando e filtrando le richieste URL ricevute. Un attaccante cercherà di creare un URL con una sequenza di caratteri speciali che, una volta interpretata dal server, sarà equivalente ad un URL proibito. Può essere difficile proteggersi da questo attacco poiché l'URL può contenere altri formati di codifica come UTF-8, Unicode-encoding, ecc. L'attaccante accede al server utilizzando un URL specifico. L'attaccante cerca di codificare alcuni caratteri speciali nell'URL. L'aggressore scopre che alcuni caratteri non sono filtrati correttamente. L'aggressore crea una richiesta di stringa URL malevola e la invia al server. Il server decodifica e interpreta la stringa URL. Sfortunatamente, poiché il filtraggio dell'input non è stato fatto correttamente, i caratteri speciali hanno conseguenze dannose.

[Find target application] Trovare l'applicazione web di destinazione che accetta un input dall'utente e recupera dati dal server [Examine existing application requests] Esaminare le richieste HTTP/GET per visualizzare il formato della query URL. Gli avversari testano per vedere se questo tipo di attacco è possibile attraverso le debolezze nella protezione di un'applicazione al Server Side Request Forgery [Richiesta dannosa] L'avversario crea una richiesta URL dannosa che assume il livello di privilegio del server per interrogare i servizi di rete interni o esterni e invia la richiesta all'applicazione

Questo attacco si rivolge ad applicazioni e software che utilizzano la funzione syslog() in modo insicuro. Se un'applicazione non utilizza esplicitamente un parametro di stringa di formato in una chiamata a syslog(), l'input dell'utente può essere inserito nel parametro di stringa di formato portando ad un attacco di iniezione di stringa di formato. Gli avversari possono quindi iniettare comandi maligni di stringa di formato nella chiamata alla funzione che porta ad un buffer overflow. Ci sono molte vulnerabilità software segnalate, la cui causa principale è un uso improprio della funzione syslog(). [L'avversario identifica un'applicazione o un programma su cui eseguire il buffer overflow. In questo attacco, gli avversari cercano applicazioni che usano syslog() in modo scorretto. [L'avversario identifica un vettore di iniezione per fornire il contenuto eccessivo al buffer dell'applicazione bersaglio. Per ogni input controllabile dall'utente che l'avversario sospetta sia vulnerabile all'iniezione di stringhe di formato, tenta di iniettare caratteri di formattazione come %n, %s, ecc. L'obiettivo è quello di manipolare la creazione della stringa utilizzando questi caratteri di formattazione. [L'avversario crea il contenuto da iniettare. Se l'intento è semplicemente quello di causare il crash del software, il contenuto deve solo consistere in una quantità eccessiva di dati casuali. Se l'intento è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario, l'avversario creerà una serie di contenuti che non solo fanno traboccare il buffer mirato, ma lo fanno in modo tale che l'indirizzo di ritorno sovrascritto sia sostituito con uno a scelta dell'avversario che punta al codice iniettato dall'avversario. [Usando il vettore di iniezione, l'avversario fornisce al programma l'iniezione della stringa di formato artigianale, causando un buffer.

La Blind SQL Injection risulta da una mitigazione insufficiente per la SQL Injection. Anche se la soppressione dei messaggi di errore del database è considerata una buona pratica, la soppressione da sola non è sufficiente a prevenire l'SQL Injection. Blind SQL Injection è una forma di SQL Injection che supera la mancanza di messaggi di errore. Senza i messaggi di errore che facilitano l'SQL Injection, l'avversario costruisce stringhe di input che sondano il bersaglio attraverso semplici espressioni booleane SQL. L'avversario può determinare se la sintassi e la struttura dell'iniezione ha avuto successo in base all'esecuzione o meno della query. Applicato iterativamente, l'avversario determina come e dove l'obiettivo è vulnerabile a SQL Injection. [Ipotizzare le query SQL nell'applicazione] [Determinare come iniettare informazioni nelle query] [Determinare l'input controllabile dall'utente suscettibile di iniezione] Determinare l'input controllabile dall'utente suscettibile di iniezione. Per ogni input controllabile dall'utente che l'avversario sospetta sia vulnerabile all'iniezione SQL, tentare di iniettare i valori determinati nel passo precedente. Se non si verifica un errore, allora l'avversario sa che l'iniezione SQL ha avuto successo. [Determinare il tipo di database] Determina il tipo di database, come MS SQL Server o Oracle o MySQL, usando condizioni logiche come parte delle query iniettate [Estrarre informazioni sullo schema del database] Estrarre informazioni sullo schema del database facendo rispondere il database a domande sì/no sullo schema. [Sfruttare la vulnerabilità di SQL Injection] Utilizzare le informazioni ottenute nei passi precedenti per iniettare con successo il database al fine di bypassare i controlli o modificare, aggiungere, recuperare o cancellare dati dal database.

Un aggressore può fornire una stringa Unicode a un componente del sistema che non conosce l'Unicode e usarla per aggirare il filtro o far sì che il meccanismo di classificazione non riesca a comprendere correttamente la richiesta. Questo potrebbe permettere all'attaccante di far passare dati dannosi oltre il filtro dei contenuti e/o possibilmente far sì che l'applicazione instradi la richiesta in modo errato. [Utilizzando un browser o uno strumento automatizzato, un attaccante segue tutti i link pubblici e le azioni su un sito web. Registra tutti i link, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. [Sonda i punti d'ingresso per individuare le vulnerabilità] L'attaccante usa i punti d'ingresso raccolti nella fase "Explore" come una lista di obiettivi e inietta vari payload codificati in Unicode per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità con una logica di validazione insufficiente e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata.

Questo attacco mira alla codifica dell'URL. Un avversario può approfittare del modo multiplo di codificare un URL e abusare dell'interpretazione dell'URL. [Indagare l'applicazione web per gli URL con parametri] Utilizzando un browser, uno strumento automatizzato o ispezionando l'applicazione, un avversario registra tutti gli URL che contengono parametri. [Sonda gli URL per individuare le vulnerabilità] L'avversario usa gli URL raccolti nella fase "Esplora" come lista di destinazione e testa i parametri con diverse codifiche di caratteri speciali per vedere come l'applicazione web li gestirà. [Utilizzando le informazioni raccolte nella fase "Experiment", l'avversario inietta caratteri speciali nell'URL utilizzando la codifica dell'URL. Questo può portare a path traversal, cross-site scripting, SQL injection, ecc.

Un attacco di questo tipo coinvolge un avversario che inserisce caratteri dannosi (come un reindirizzamento XSS) in un nome file, direttamente o indirettamente, che viene poi utilizzato dal software di destinazione per generare testo HTML o altro contenuto potenzialmente eseguibile. Molti siti Web si basano su contenuti generati dagli utenti e creano dinamicamente risorse come file, nomi di file e collegamenti URL direttamente dai dati forniti dall'utente. In questo modello di attacco, l'aggressore carica codice che può essere eseguito nel browser client e/o reindirizzare il browser client a un sito di sua proprietà. Tutte le varianti di payload di attacco XSS possono essere utilizzate per superare e sfruttare queste vulnerabilità.

Questo attacco mira all'uso del backslash nella codifica alternativa. Un avversario può fornire un backslash come carattere iniziale e far credere al parser che il carattere successivo sia speciale. Questo è chiamato escape. Usando questo trucco, l'avversario cerca di sfruttare modi alternativi per codificare lo stesso carattere, il che porta a problemi di filtraggio e apre vie di attacco. [Utilizzando un browser, uno strumento automatico o ispezionando l'applicazione, un avversario registra tutti i punti di ingresso all'applicazione. [Sonda i punti d'ingresso per individuare le vulnerabilità] L'avversario usa i punti d'ingresso raccolti nella fase "Esplora" come una lista di obiettivi e tenta di sfuggire a più caratteri speciali diversi usando una barra rovesciata. [Manipolare l'input] Una volta che l'avversario determina come bypassare i filtri che filtrano i caratteri speciali usando una barra rovesciata, manipolerà l'input dell'utente in un modo che non è previsto dall'applicazione.

Questo attacco mira alla codifica dei caratteri Slash. Un avversario cercherebbe di sfruttare i comuni problemi di filtraggio relativi all'uso dei caratteri slash per ottenere l'accesso alle risorse sull'host di destinazione. I sistemi basati su directory, come i file system e i database, tipicamente usano il carattere slash per indicare l'attraversamento tra directory o altri componenti del contenitore. Per oscuri motivi storici, i PC (e, di conseguenza, i sistemi operativi Microsoft) scelgono di utilizzare un backslash, mentre il mondo UNIX tipicamente fa uso della barra avanti. Il risultato schizofrenico è che molti sistemi basati su MS devono comprendere entrambe le forme di slash. Questo dà all'avversario molte opportunità di scoprire e abusare di un certo numero di problemi di filtraggio comuni. L'obiettivo di questo schema è scoprire il software del server che applica i filtri solo ad una versione, ma non all'altra. [Utilizzando un browser, uno strumento automatico o ispezionando l'applicazione, un avversario registra tutti i punti di ingresso all'applicazione. [Sonda i punti d'ingresso per individuare le vulnerabilità] L'avversario usa i punti d'ingresso raccolti nella fase "Esplora" come una lista di obiettivi e cerca le aree in cui l'input dell'utente viene usato per accedere alle risorse sull'host di destinazione. L'avversario tenta diverse codifiche di caratteri slash per bypassare i filtri di input. [Una volta che l'avversario determina come bypassare i filtri che filtrano i caratteri slash, manipola l'input dell'utente per includere gli slash al fine di attraversare le directory e accedere a risorse che non sono destinate all'utente.

Questo attacco prende di mira librerie o moduli di codice condiviso che sono vulnerabili agli attacchi di buffer overflow. Un avversario che ha conoscenza delle librerie o del codice condiviso noto e vulnerabile può facilmente prendere di mira il software che fa uso di queste librerie. Tutti i client che fanno uso della libreria di codice diventano quindi vulnerabili per associazione. Questo ha un effetto molto ampio sulla sicurezza di un sistema, di solito colpendo più di un processo software. [Identificare l'applicazione bersaglio] L'avversario, con la conoscenza delle librerie vulnerabili o dei moduli di codice condiviso, identifica un'applicazione o un programma bersaglio che ne fa uso. [Trovare il vettore di iniezione] L'avversario tenta di utilizzare l'API e, se ci riesce, invia una grande quantità di dati per vedere se l'attacco di buffer overflow funziona davvero. [L'avversario crea il contenuto da iniettare in base alla sua conoscenza della vulnerabilità e al risultato desiderato. Se l'intento è semplicemente quello di causare il crash del software, il contenuto deve solo consistere in una quantità eccessiva di dati casuali. Se l'intento è quello di sfruttare l'overflow per l'esecuzione di codice arbitrario, l'avversario creerà una serie di contenuti che non solo fanno traboccare il buffer mirato, ma lo fanno in modo tale che l'indirizzo di ritorno sovrascritto viene sostituito con uno a scelta dell'avversario che punta al codice iniettato dall'avversario. [Utilizzando l'API come vettore di iniezione, l'avversario inietta il contenuto di overflow artigianale nel buffer.

Questo attacco è una variazione specifica sullo sfruttamento di codifiche alternative per aggirare la logica di convalida. Questo attacco sfrutta la possibilità di codificare l'input potenzialmente dannoso in UTF-8 e presentarlo alle applicazioni che non si aspettano o non sono efficaci nel convalidare questo standard di codifica rendendo difficile il filtraggio dell'input. UTF-8 (8-bit UCS/Unicode Transformation Format) è una codifica di caratteri a lunghezza variabile per Unicode. I caratteri UTF-8 legali sono lunghi da uno a quattro byte. Tuttavia, la prima versione della specifica UTF-8 ha sbagliato alcune voci (in alcuni casi ha permesso caratteri troppo lunghi). I codificatori UTF-8 dovrebbero usare la codifica "più breve possibile", ma i decodificatori ingenui possono accettare codifiche più lunghe del necessario. Secondo la RFC 3629, una forma particolarmente sottile di questo attacco può essere effettuata contro un parser che esegue controlli di validità critici per la sicurezza contro la forma codificata UTF-8 del suo input, ma interpreta certe sequenze di ottetti illegali come caratteri. [Utilizzando un browser o uno strumento automatizzato, un attaccante segue tutti i link pubblici e le azioni su un sito web. Registra tutti i link, i moduli, le risorse a cui si accede e tutti gli altri potenziali punti di ingresso dell'applicazione web. [Sonda i punti d'ingresso per individuare le vulnerabilità] L'attaccante utilizza i punti d'ingresso raccolti nella fase "Explore" come lista di destinazione e inietta vari payload codificati in UTF-8 per determinare se un punto d'ingresso rappresenta effettivamente una vulnerabilità con una logica di validazione insufficiente e per caratterizzare la misura in cui la vulnerabilità può essere sfruttata.

Gli attacchi Web Logs Tampering coinvolgono un attaccante che inietta, cancella o manomette in altro modo il contenuto dei log web tipicamente allo scopo di mascherare altri comportamenti dannosi. Inoltre, la scrittura di dati dannosi nei file di log può prendere di mira lavori, filtri, rapporti e altri agenti che elaborano i log in un modello di attacco asincrono. Questo schema di attacco è simile a "Log Injection-Tampering-Forging", tranne che in questo caso, l'attacco prende di mira i log del server web e non l'applicazione. [L'attaccante osserva il sistema e cerca indicatori di quale utilità di log è utilizzata dal server web. [Determinare il contenuto iniettabile] L'attaccante lancia varie azioni registrate con dati dannosi per determinare quale tipo di iniezione di log è possibile. [Manipolare i file di log] L'attaccante altera il contenuto dei log direttamente attraverso la manipolazione o la falsificazione o indirettamente attraverso l'iniezione di richieste appositamente elaborate che il server web riceverà e scriverà nei log. Questo tipo di attacco segue tipicamente un altro attacco e viene utilizzato per cercare di coprire le tracce dell'attacco precedente.

Un attaccante può creare un input speciale controllabile dall'utente che consiste in espressioni XPath per iniettare il database XML e bypassare l'autenticazione o ottenere informazioni che normalmente non sarebbero in grado di ottenere. XPath Injection permette ad un attaccante di parlare direttamente con il database XML, aggirando così l'applicazione completamente. XPath Injection deriva dall'incapacità di un'applicazione di sanitizzare correttamente l'input utilizzato come parte di espressioni XPath dinamiche usate per interrogare un database XML. [Utilizzando un browser o uno strumento automatizzato, un avversario registra tutte le istanze di input controllabili dall'utente utilizzate per costruire le query XPath. [Determinare la struttura delle query] Usando mezzi manuali o automatici, testare gli input trovati per le debolezze di XPath. [Iniettare il contenuto nella query XPath] Creare un contenuto dannoso contenente espressioni XPath che non viene convalidato dall'applicazione e viene eseguito come parte delle query XPath.

Questo attacco utilizza i frequenti roundtrip client-server nella conversazione Ajax per scansionare un sistema. Mentre Ajax non apre nuove vulnerabilità di per sé, le ottimizza dal punto di vista dell'attaccante. Un primo passo comune per un attaccante è il footprint dell'ambiente di destinazione per capire quali attacchi funzioneranno. Poiché il footprinting si basa sull'enumerazione, il modello di conversazione di richieste e risposte rapide e multiple che sono tipiche nelle applicazioni Ajax permettono ad un attaccante di cercare molte vulnerabilità, porte conosciute, posizioni di rete e così via. La conoscenza acquisita attraverso Ajax fingerprinting può essere utilizzata per supportare altri attacchi, come XSS. [Utilizzando un browser o uno strumento automatizzato, un avversario invia richieste ad una pagina web e registra la risposta HTML ricevuta. Gli avversari quindi analizzano l'HTML per identificare qualsiasi architettura JavaScript sottostante nota. Questo può aiutare nella mappatura delle vulnerabilità pubblicamente note alla pagina web e può anche aiutare l'avversario a indovinare l'architettura dell'applicazione e il funzionamento interno di un sistema.

In questo tipo di attacco, un avversario inietta comandi del sistema operativo in funzioni di applicazioni esistenti. Un'applicazione che utilizza input non fidati per costruire stringhe di comando è vulnerabile. Un avversario può sfruttare l'iniezione di comandi del sistema operativo in un'applicazione per elevare i privilegi, eseguire comandi arbitrari e compromettere il sistema operativo sottostante. L'attaccante determina l'input controllabile dall'utente che viene passato come parte di un comando al sistema operativo sottostante. A seconda che l'applicazione sfruttata sia remota o locale, l'attaccante crea l'input dannoso appropriato, contenente i comandi del sistema operativo, da passare all'applicazione [Eseguire comandi dannosi] L'attaccante può rubare informazioni, installare un meccanismo di accesso back door, elevare i privilegi o compromettere il sistema in qualche altro modo.

Questo attacco prende di mira le utilità a riga di comando disponibili in un certo numero di shell. Un avversario può sfruttare una vulnerabilità trovata in un'utilità a riga di comando per aumentare i privilegi a root. [L'avversario prima trova un sistema di destinazione su cui vuole ottenere privilegi elevati. Questo potrebbe essere un sistema a cui ha già un certo livello di accesso o un sistema a cui otterrà un accesso non autorizzato con un privilegio inferiore usando altri mezzi. [L'avversario identifica le utilità della riga di comando esposte dall'host di destinazione che contengono vulnerabilità di buffer overflow. L'avversario probabilmente sa quali utility hanno queste vulnerabilità e quali sono le versioni interessate, quindi otterrà anche i numeri di versione di queste utility. [Una volta che l'avversario ha trovato un'utilità vulnerabile, userà la sua conoscenza della vulnerabilità per creare il comando che sfrutterà il buffer overflow. [Usando il vettore di iniezione, l'avversario esegue il comando creato, ottenendo privilegi elevati sulla macchina.