Da Microsoft uno strumento contro gli attacchi SQL Injection

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/sicurez...ion_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.

[k0nt3]

la vera soluzione è usare una piattaforma tipo JavaEE

[waielsi]

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

[lupotana]

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

Cosa centra Microsoft?

[Rubberick]

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...

[Human_Sorrow]

@ 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

[DanieleG]

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

[Bad-WOLF-]

Usando Stored Procedure si riduce notevolmente questa problema

[k0nt3]

Originariamente inviato da Human_Sorrow

@ 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

[Human_Sorrow]

@ 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]

Originariamente inviato da Human_Sorrow

@ 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)

[Human_Sorrow]

@ 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]

Originariamente inviato da Human_Sorrow

@ 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)

[Norskeningia]

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

[Lck84]

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.

[II ARROWS]

Originariamente inviato da k0nt3

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.

[Norskeningia]

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.

[sierrodc]

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.

[Robotica]

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.

[afterburner]

Originariamente inviato da k0nt3

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.