Da Microsoft uno strumento contro gli attacchi SQL Injection

Microsoft ha presentato la beta di UrlScan filter 3.0, un tool per IIS 7 per la protezione contro attacchi di tipo SQL Injection
di Fabio Gozzo pubblicata il 26 Giugno 2008, alle 10:56 nel canale SicurezzaMicrosoft
21 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoL'MVC non è che firmato Java ... E' un pattern utilizzabile su tutti i linguaggi OO ...
Il CMS che ho sviluppato in ASP.NET segue l'MVC ...
E sopratutto non è il pattern che ti risolve il problema.
Cioè che ti risolve il problema è evitare di mandare al DB un comando del tipo:
...WHERE Name='hacker' AND pwd='pippo' or 0=0--
bye
L'MVC non è che firmato Java ... E' un pattern utilizzabile su tutti i linguaggi OO ...
Il CMS che ho sviluppato in ASP.NET segue l'MVC ...
E sopratutto non è il pattern che ti risolve il problema.
Cioè che ti risolve il problema è evitare di mandare al DB un comando del tipo:
...WHERE Name='hacker' AND pwd='pippo' or 0=0--
bye
beh ovvio che MVC non è firmato Java, ho solo detto che JavaEE è pensato per usare questo pattern.
inoltre usando Java Persistence API non vedrai nemmeno l'ombra di codice SQL perchè le tuple del database sottostante sono mappate su oggetti.
con ogni probabilità anche in .NET c'è una cosa simile (e magari anche per PHP)
In Java credo esista qualcosa di analogo al LinQ ma non ricordo come si chiama
Ciò non toglie che indipendentemente dalla tecnologia, dal pattern di visualizzazione (MVC o no) che si sceglie, se sotto sotto si concatenano stringhe a mano per accedere al DB si sarà sempre aperti a questo tipo di bachi.
LinQ in realtà è una estensione del linguaggio C# che permette la formulazione dichiarativa di query su oggetti. Con l'ausilio dell'Entity Framework (che è un ORM come Hibernate o NHibernate e compagnia bella) si può accedere ai DB con una sintassi integrata al linguaggio.
"Cosa significa indipendenza dei dati?"
È una delle basi di un DBMS, non mi pare niente di nuovo quello che hai scritto.
Indipendenza dai dati
Non guardare dal punto di vista del DBMS, guarda dal punto di vista del linguaggio di programmazione.Se la tua query e'
string query = SELECT * FROM USER_PWD WHERE user=$1 and pass=$2;
allora a tutti gli effetti la tua query e' un dato. qui hai mischiato dati (una variabile stringa) con logica applicativa ( query SQL ).
Pur essendo un approccio molto comodo ( permette di costruirsi query dinamiche a piacere semplicemente formattando una stringa )
e' anche un approccio sensibile agli exploit ( modifichi una stringa, modifichi una query ).
sfruttando il pattern MVC il tuo applicativo ( o servlet che sia ) non conosce le QUERY non conosce il database non conosce i dati ma solo la logica e quindi e' meno a rischio.
Il mio prof di sicurezza alla domanda "se si utilizzano stored procedures si è immuni da attacchi sql injection" lui ha risposto che non è vero; Ha detto che, per esempio, in oracle era possibile iniettare funzioni del dbms nei parametri delle sp e quindi effettuare attacchi...
Non è un argomento stupido, e un altro analizzatore è ben accetto.
PS: per gli amanti di hibernate/nhibernate (tra cui io) avevo letto che è vero che si è più o meno immuni da sql injection, ma restano attacchi di HQL o come si chiama.
Quindi per me la soluzione è fare mooolta attenzione e sentirsi sempre attaccabili.
l'architettura non basta
ho fatto sql injection a piattaforme jsp.viceversa non sono riuscito ad aggredire alcune applicazioni php.
dipende molto da come viene scritto il sw non dal linguaggio o dall'architettura utilizzati.
usare stored procedure in oracle aiuta a difendersi ma non rende immuni. E' molto + efficace formattare i parametri in ingresso, magari.
buone iniezioni a tutti.
Esattamente!
Far passare delle sql injection o php injection su pagine create in php e' molto piu' facile che su delle java servlet con dietro una piattaforma middleware come websphere o weblogic.
Comunque, alla fine di tutto, si tratta di bilanciare spese e benefici. La sicurezza costa.
Sebbene hwupgrade sia un bel sito e abbia un bel forum, mandarlo in bancarotta per fare un forum con architettura J2EE non ha senso. Altro discorso per banche - assicurazioni - operatori di comunicazioni dove questo tipo di attacchi non devono assolutamente passare e gli investimenti sulla sicurezza sono almeno a 6 zeri.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".