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
 

Microsoft ha appena presentato al pubblico UrlScan filter 3.0 Beta, uno strumento per il server Web IIS 7 atto alla protezione contro uno degli attacchi più semplici ma anche più insidiosi al mondo, l'SQL Injection. Nel corso del mese di aprile, abbiamo assistito ad una vera e propria ondata di attacchi SQL Injection, in seguito alla quale erano risultati infettati oltre 500.000 siti Web.

Questo tipo di attacco è sostanzialmente indirizzato a colpire siti Web che si appoggiano ad un database, ad esempio un forum o un blog, su cui è consentito agli utenti di inserire contenuti, che vengono poi memorizzati all'interno del database del sito stesso. L'attacco sfrutta l'inefficienza dei controlli sui dati ricevuti in ingresso dal sito per inserire del codice maligno all'interno della base di dati, infettando conseguentemente le pagine del sito

Microsoft era stata in un primo momento ritenuta colpevole di quanto accaduto, rea di una fantomatica falla di sicurezza nel server Web IIS. In realtà il problema era dovuto alla scarsa qualità, sul fronte della sicurezza, del codice sorgente dei siti Web. Ciò ha tuttavia stimolato il colosso di Redmond ad aggiornare il proprio software UrlScan filter, che nella precedente versione 2.5 era compatibile solamente con IIS 6.0.

La nuova versione 3.0 di UrlScan filter è indirizzata alla nuova release del server Web IIS 7.0, che è parte integrante di Windows Server 2008. UrlScan non è in grado di bloccare tutte le tipologie di attacco basate su SQL Injection, tuttavia renderà inefficaci gli attacchi più comuni. In aggiunta, Microsoft ha rilasciato sottoforma di technology preview uno strumento che si occupa di analizzare il codice sorgente delle pagine realizzate in ASP.NET al fine di ricercare eventuali porzioni di codice che potrebbero essere vulnerabili ad attacchi di questo tipo.

Il colosso di Redmond sta inoltre lavorando congiuntamente con i laboratori di ricerca di HP per lo sviluppo di Scrawlr: si tratta di uno strumento che si occupa di effettuare il crawling di un sito web, andando ad analizzare i parametri di ogni singola pagina, alla ricerca di vulnerabilità ad attacchi di tipo SQL Injection. In accordo con quanto riportato sul blog di HP, Scrawlr è molto veloce ed è dotato di un motore intelligente in grado di creare dinamicamente codice da iniettare nel database del sito.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

21 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
k0nt326 Giugno 2008, 11:50 #1
la vera soluzione è usare una piattaforma tipo JavaEE
waielsi26 Giugno 2008, 11:53 #2

la solita microsoft che inventa l'acqua calda...

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/So...urity_Analyzers
lupotana26 Giugno 2008, 12:02 #3
Ma per combattere la SQL INJECTION non basta usare chiamate con parametri ?

Cosa centra Microsoft?
Rubberick26 Giugno 2008, 12:16 #4
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_Sorrow26 Giugno 2008, 12:21 #5
@ 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
DanieleG26 Giugno 2008, 12:22 #6
Che bello vedere i soliti commenti che non c'entrano niente solo per dare contro a MS...
Bad-WOLF-26 Giugno 2008, 12:23 #7
Usando Stored Procedure si riduce notevolmente questa problema
k0nt326 Giugno 2008, 12:27 #8
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_Sorrow26 Giugno 2008, 12:35 #9
@ 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
k0nt326 Giugno 2008, 12:42 #10
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)

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