Da Microsoft uno strumento contro gli attacchi SQL Injection

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 pubblicata il , alle 10:56 nel canale Sicurezza
Microsoft
 
I migliori sconti su Amazon oggi

TCL 55V6C TV 55'' 4K UHD Smart LED TV, 4K HDR, Google TV con design senza bordi (Dolby Audio, Motion Clarity, compatibile con Google Assistant e Alexa)

299.00€ Compra ora
-17%

Apple Portatile MacBook Air 13'' con chip M4 (2025): progettato per Apple Intelligence, display Liquid Retina da 13,6'', 16GB di memoria unificata, 256GB di archiviazione SSD, Touch ID; Argento

1149.00 949.00€ Compra ora
-17%

LG SQC2 Soundbar TV 300W, 2.1 Canali con Subwoofer Wireless, Soundbar Dolby Digital, Bluetooth, Ingresso Ottico, Ingresso AUX 3,5mm, USB

117.03€ Compra ora
21 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Human_Sorrow26 Giugno 2008, 12:54 #11
@ 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
k0nt326 Giugno 2008, 13:04 #12
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)
Norskeningia26 Giugno 2008, 13:45 #13
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
Lck8426 Giugno 2008, 13:51 #14
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 ARROWS26 Giugno 2008, 13:54 #15
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.
Norskeningia26 Giugno 2008, 14:06 #16

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.
sierrodc26 Giugno 2008, 15:17 #17
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.
Robotica26 Giugno 2008, 18:37 #18

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.
afterburner26 Giugno 2008, 19:14 #19
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.
M4R1|<27 Giugno 2008, 18:52 #20
parole di darkfuneral: è eludibile come la 2.5 i server si bucano cmq....
« Pagina Precedente     Pagina Successiva »

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

La discussione è consultabile anche qui, sul forum.
 
^