» continua
» continua
» continua
Gli attacchi fault-injection esistono da quando c'è Internet e permettono l'accesso a un sistema attraverso un'applicazione Web. Con l'esplosiva crescita delle applicazioni, e con la sempre maggiore migrazione verso il Web, gli attacchi di injection sono diventati una preoccupazione sempre più rilevante. In questo articolo vedremo come si comportano gli attacchi fault-injection, le differenti varietà di tali attacchi e alcune best practice di sviluppo utili ad assicurarvi che i sistemi della vostra organizzazione non vengano colpiti.
Alcuni fault-injection sono basati su script, ovvero usano linguaggi come Javascript e Php. Con le nuove tecnologie Web 2.0 che si fondano sul linguaggio di scripting, gli attacchi di injection sono diventati più frequenti e più specializzati. La gamma di tecnologie Web 2.0 include Xml, Rss e Ajax, che possono nascondere il codice maligno di injection.
Poiché gli attacchi di injection vengono spesso gestiti dalle applicazioni Web sotto forma di codice malicius embedded, non sono intrusivi come i tradizionali attacchi della rete e passano inosservati sotto il radar dei tradizionali sistemi di Ips e Ids. Ciò aggiunge un grado di complessità al processo di rilevazione.
Tipi di attacchi fault-injection
Secondo l'Open Web Application Security Project (Owasp), che fornisce agli sviluppatori consigli sulle pratiche sicure di codificazione Web, esistono due tipi di attacchi injection. I difetti di injection e il cross site scripting (Xss) sono fra le 10 principali vulnerabilità definite dall'Owasp. Entrambi implicano l'inserimento del codice maligno in un'applicazione Web, solitamente tramite un browser.
L'attacco più comune e più insidioso delle due categorie di Owasp è Xss. Questo è solitamente eseguito tramite Javascript ma può anche essere usato un qualunque altro linguaggio di scripting. Xss può permettere l'accesso maligno a un sistema di computer attraverso il furto delle credenziali di autenticazione di un utente legittimo di un'applicazione Web.
All'interno dell'altra categoria di Owasp, i difetti di injection, l'Sql injection è di gran lunga il più comune. L'Sql injection si basa sull'inserimento di comandi Sql in un campo di una form di un browser Web, consentendo così l'accesso al database che sta facendo girare l'applicazione Web. Diversamente da Xss, l'Sql injection prova a ottenere i dati che sottendono all'applicazione, piuttosto che tentare di rubare l'identificativo dell'utente e la password.
Difendersi dalla fault-injection
Contro gli attacchi injection, ci sono due metodi principali di difesa. Uno consiste nella codificazione sicura e nel project management, come sostenuto dall'Owasp, e l'altro è una strategia più basata sull'hardware con firewall a livello delle applicazioni.
La prima regola base della codifica volta a impedire gli attacchi injection è di filtrare tutti gli l'input all'applicazione Web. Questo vuol dire includere qualsiasi cosa sia presentato da un pagina Web sottoforma di form, campo nascosto o persino inserito in un URL. I colpevoli sono comuni caratteri non-alfanumerici, come “!”, “#”, “<” e “>”, che possono avviare processi di back-end sui server di applicazioni o Web e permettere l'accesso non autorizzato.
Per l'Sql injection, l'apostrofo singolo (') fa parte di una dichiarazione SQL. Una volta inserito con i giusti caratteri in un campo su una pagina Web, se non filtrato correttamente, può iniziare una query Sql verso un database di back-end. Se il database contiene informazioni di un cliente o i suoi dati sensibili, può rappresentare una miniera di oro per gli attacker malintenzionati.
Nel caso dell'Xss, il colpevole principale è il tag "script" che si aggancia allo Javascript maligno o ad altri codici di script che l'attacker sta provando a inserire nel sito Web. Il filtro di tali “agganci” è il primo passo nella sconfitta di questi attacchi.
La guida alle principali vulnerabilità definite dall'OWASP contiene spiegazioni dettagliate con gli esempi di codice per i principali linguaggi di codifica comuni, come Java, .Net e Php. Inoltre, offre le best practice di codifica, quali la convalida dell'input, l'uso delle procedure memorizzate quando possibile, l'encoding di uno specifico output e la validazione di una white list, giusto per nominarne alcune.
Test di sicurezza nello sviluppo del software
Nel lifecycle di sviluppo dell'applicazione dovrebbero essere sviluppate procedure di codifica sicura. Alcune specifiche tecniche dovrebbero indicare nel dettaglio le procedure di convalida dell'input per l'integrazione nella codifica ed è bene fare dei test di sicurezza durante il ciclo di sviluppo del software.
Due popolari tool per il test di penetration che controllano l'injection sia Xss sia Sql sono WebInspect di Dynamics di SPI (recentemente comprato da Hewlett-Packard) e AppScan di Watchfire (recentemente comprato da Ibm). Entrambi effettuano la scansione delle applicazioni Web per individuare difetti che possono permette l'injection e forniscono una segnalazione dettagliata utile agli sviluppatori per rintracciano tali bug.
Un altro metodo sono i tool per l'analisi statica del codice, come quelli offerti da Fortify Software. I due approcci sono differenti: uno è uno scanner e l'altro è un analizzatore di codice. La scelta di un tool o di un altro dovrebbe basarsi sui bisogni e sulle risorse disponibili per lo sviluppo.
In un approccio basato sull'hardware, i firewall delle applicazioni Web possono filtrare gli attacchi di injection. Diversamente dai firewall tradizionali, che controllano gli header del pacchetto e consentono o bloccano il traffico basandosi sul tipo e sull'origine del pacchetto, i firewall a livello delle applicazioni controllano il contenuto dei pacchetti per individuare pattern tipici del codice maligno, compreso quelli degli attacchi injection.
E' questo un mercato ancora in fase di sviluppo e perciò va approcciato con attenzione. In altre parole, determinati appliance e firewall network based dovrebbero essere completamente testati prima dell'installazione.
Non solo. Alcuni prodotti sono più orientati alla protezione dalle minacce dell'instant messaging e dell'email e non assicurano la protezione contro gli attacchi injection. Altri esplorano gli Url per bloccare l'accesso a siti inadeguati. Ma questo è un mercato in forte crescita e, dato che gli attacchi injection diventano sempre più sofisticati, sicuramente a breve saranno disponibili strumenti di difesa in grado di soddisfare ogni tipo di esigenza.
