Link alla notizia: http://www.hwupgrade.it/news/sicurezza/da-microsoft-uno-strumento-contro-gli-attacchi-sql-injection_25774.html

Microsoft ha presentato la beta di UrlScan filter 3.0, un tool per IIS 7 per la protezione contro attacchi di tipo SQL Injection

Click sul link per visualizzare la notizia.

la vera soluzione è usare una piattaforma tipo JavaEE

ce ne sono tanti di tool come questo supportati e sviluppati dalla comunita' open source che non si limitano al solo ASP.NET.

si puo' trovare un buon elenco a http://samate.nist.gov/index.php/Source_Code_Security_Analyzers

Ma per combattere la SQL INJECTION non basta usare chiamate con parametri ?

Cosa centra Microsoft?

Ma oramai chi usa + le query dirette non parsate...

Io personalmente mi sono scritto una classe di astrazione che fa il lavoro sporco ma esiste anche un mare di materiale pronto... librerie potentissime, magari nn troppo leggere ma ci sono...

@ K0nt3

ma che c'entra Java con i Database !??!

il problema della SQL INJECTION esiste su tutti i DMBS mica solo su MS SQL Server, ed è un problema riguardante il codice scritto male dal programmatore non il linguaggio o il DBMS stesso.

bye

Che bello vedere i soliti commenti che non c'entrano niente solo per dare contro a MS... :rolleyes:

Usando Stored Procedure si riduce notevolmente questa problema

@ K0nt3

ma che c'entra Java con i Database !??!

il problema della SQL INJECTION esiste su tutti i DMBS mica solo su MS SQL Server, ed è un problema riguardante il codice scritto male dal programmatore non il linguaggio o il DBMS stesso.

bye
non ho parlato di linguaggio Java, ma di piattaforma JavaEE

@ K0nt3

per me JavaEE è la versione Enteprise Edition di Java così come esiste Java2ME per i cellulari e comunque non capisco che c'entra con i DB.

Ovvero faccio un'applicazione con "la piattaforma JavaEE" e ci attacco un DB MySQL ... Sono immune da SQL Injection ??
I don't think about ...


bye

@ K0nt3

per me JavaEE è la versione Enteprise Edition di Java così come esiste Java2ME per i cellulari e comunque non capisco che c'entra con i DB.

Ovvero faccio un'applicazione con "la piattaforma JavaEE" e ci attacco un DB MySQL ... Sono immune da SQL Injection ??
I don't think about ...


bye
uhm I think about

in JavaEE viene usato il pattern MVC che risolve il problema delle SQL injection con una separazione netta tra DBMS e logica applicativa (vedi Java Persistence API).
ovviamente è sempre possibile scrivere codice sbagliato anche in JavaEE, ma JavaEE offre gli strumenti necessari per sconfiggere le SQL injection.

chiediti perchè hwupgrade usa php mentre la mia banca online usa jsp (moltro probabilmente immerso nella piattaforma JavaEE)

@ K0nt3

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

@ K0nt3

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 .NET c'e' linq che risolve questo problema, ovviamente ci sono MILLEMILA alternative per proteggersi contro l'SQL Injection. Pero' ci sono piattaforme dove non e' possibile riscrivere tutto sfruttando le nuove tecnologie e bisogna rassegnarsi a fixare i bachi.

In Java credo esista qualcosa di analogo al LinQ ma non ricordo come si chiama :D

Beh, la Java PErsistence API è una delle tanti alternative per l'ORM (Object/Relational mapping) e che quindi si occupa di astrarre tutti gli accessi al DB. Sia su Java, che su .NET, che sulla maggior parte dei linguaggi esistono diverse alternative e quindi per programmatori consci del problema subire SQL Injection è piuttosto difficile.
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.

in JavaEE viene usato il pattern MVC che risolve il problema delle SQL injection con una separazione netta tra DBMS e logica applicativa (vedi Java Persistence API).Ti dirò, è un anno che la mia prof di info continua a mettere questa domanda nelle verifiche per colpa delle capre dei miei compagni:
"Cosa significa indipendenza dei dati?"

È una delle basi di un DBMS, non mi pare niente di nuovo quello che hai scritto.

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.

Io volevo solo dire una piccola cosa:

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.

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.

chiediti perchè hwupgrade usa php mentre la mia banca online usa jsp (moltro probabilmente immerso nella piattaforma JavaEE)

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.

parole di darkfuneral: è eludibile come la 2.5 :D i server si bucano cmq....

Sebbene hwupgrade sia un bel sito e abbia un bel forum, mandarlo in bancarotta per fare un forum con architettura J2EE non ha senso...
In bancarotta per il solo fatto di usare java ee?? :eek: