Sql Injection Cross Site Scripting

Problem.

Ultimamente si stanno verificando attacchi massivi che bucano soprattutto i siti sviluppati con il vecchio ASP. Ma non solo, anche ASP.Net è vulnerabile ad attacchi che si verificano da qualche mese e che stanno causando grossi problemi a portali di aziende organizzazioni importanti di tutto il mondo.

Questo attacco prevede:

- la scansione dei parametri utilizzati nelle pagine (get e post)
- la valorizzazione di tali paramentri con comandi sql scritti in codice binario
- la conseguente esecuzione dei comandi sql che non fanno altro che appendere, in tutti i campi testuali, un tag html come ad esempio "<script src=http://www.pingbnr.com/b.js> </script>"

L'effetto è che quando gli utenti accedono al sito viene eseguita una chiamata cross site scripting al file js (sia che la pagina si veda sia che la pagina non si veda in quanto spaccata dal tag - pensate ad una drop down list che carica il valore dal db) , che non fa altro che scrivere un iframe. E' proprio la pagina richiamata dall'iframe che legge tutti i contenuti del cookie dell'utente. La conseguenza si può benissimo intuire: centinaia di migliaia di dati degli utenti salvati nel database degli hackers.

Per saperne di più http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx

Solutions.

1) La soluzione a questo tipo di attacco è proprio quella di proteggere e controllare i campi utili a costruire la sintassi sql (cosa che ho automatizzato già da un pò di tempo con una dll com+ per i siti asp e ultimamente con una dll .net per i siti asp.net) .
Microsoft, dopo aver notato la crescita di questo tipo di attacco mette a disposizione un tool che verifica l'intrusività del codice sviluppato http://blog.html.it/archivi/2008/06/27/un-tool-microsoft-contro-la-sql-injection.php

Ovviamente proteggere le applicazioni richiedono anche tempo e denaro. Il cliente non ha però scelta, deve investire in questo.

2) Chi gestisce i siti dei clienti si ritrovano però a far fronte ad azioni molto più immediate rispetto al lavoro di coprire le falle, proprio per evitare il down prolungato delle loro applicazioni.
Per questo motivo e per le vicissitudini vissute in prima persona vorrei condividere il mio intervento su un cliente.
Il problema principale è stato appunto quello di ripulire il codice maligno dalle tabelle.  Ripristinare un backup del database non è sempre la soluzione migliore anche perché:

- l'attacco può essere avvenuto in giorni diversi e quindi è difficile stabilire il backup opportuno
- il cliente può aver aggiornato contenuti durante i giorni di presenza dello script maligno
- finché non si implementa la sicurezza delle pagine il sito è a rischio quotidiano di nuovi attacchi
 
In questi casi rimane che ripulire il codice e monitorare l'applicazione. Ho pertanto implementato una procedura (riutilizzando proprio lo script di chi ha attaccato) che, sfruttando le tabelle di sistema, non fa altro che scandire tutti i campi testuali di tutte le tabelle e rimuovere gli script maligni. Tali script vengono enumerati a loro volta in una tabella degli script maligni e quindi eliminati attraverso l'esecuzione di una stored procedure.

Inoltre, attraverso un job schedulato di sql, è possibile automatizzare l'intervento quotidianamente, finchè non viene rilasciata la release sicura dell'applicazione.

Un'altra azione da fare è di negare all'utente di sql, utilizzato per interagire con le tabella della vostra applicazione,  l'accesso alle tabelle di sistema. In questa maniera non si dà la possibilità di scandire le tabelle del database.

A chi fosse interessato posso inviare l'intero script sql che ripulisce il database del codice maligno.

posted @ mercoledì 2 luglio 2008 15:48

Print

Comments on this entry:

# re: Sql Injection Cross Site Scripting

Left by Antonio at 07/07/2008 12:10
Gravatar
Ciao. Utile sapere di non essere l'unico alle prese con questo genere di problemi, ultimamante :)
Direi che la soluzione migliore sia quella di evitare che l'accoutn sql utilizzato abbia accesso agli oggetti di sistema.
Per ripulire le tabelle, io ho utilizzato lo stesso script utilizzato dagli hacher ;)

# re: Sql Injection Cross Site Scripting

Left by Cristian at 25/09/2008 18:28
Gravatar
Io ho trovato molto efficace questo tool su SnowCovered.com, si chiama edWebSecurity e da quando l'ho applicato ai miei siti clienti non ho più avuto alcuna intrusione di tipo SQL Injection ne ASCII SQL Injection.
Unica nota è che la licenza è monouso (per un solo sito) ma visto il costo non eccessivone ho comprato una per ogni cliente con ottimi risultati.

# re: Sql Injection Cross Site Scripting

Left by sohbet at 08/02/2009 15:39
Gravatar
Comments have been closed on this topic.
«luglio»
domlunmarmergiovensab
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678