Mi ricollego a questo post di Massimiliano riguardo gli ultimi attacchi di Sql Injection che stanno subendo un pò tutti.
Ricercando su goggle per 'www.bigadnet.com', vedrete subito una quantità di siti impressionante, tutti purtroppo sviluppati con il vecchio ASP 3.0. Molti, sempre purtroppo, riguardano siti istituzionali che fortunatamente sono stati già messi a posto, per ora. Se si conta che bigadnet è solo uno dei domini che si occupano di mandare in giro certe schifezze... a questo indirizzo trovate una lista aggiornata di altri domini.
Il meccanismo di injection è piuttosto semplice anche se raffinato: si concentrano sugli id numerici, quindi tutte le funzioni di controllo che siamo abituati ad avere sul vecchio ASP, se ne vanno a donne di facili costumi. Anche qualsiasi tag stripping, ovviamente, non funziona, visto che la stringa è encodata come ha dimostrato Massimiliano. Inoltre, l'attacco si scatena sulle querystring, che molti sviluppatori (sigh) sono abituati a considerare "sicure" (eh, tanto chi mai si metterà a giocare con le querystring?? eh? eh... :P).
Praticamente, al web server arriva una richiesta di questo genere:
pagina.asp?IdNumerico=888;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST([..CUT della mappazza])--
Come ho detto prima, ne controllo apici ne tag stripping ci mettono a posto, quindi tutta la mappazza arriva bella diretta sul nostro db.
Gli attacchi sono di due tipi, uno che come ha mostrato massimiliano si "limita" a cambiare tutti i campi di un certo tipo aggiungendo la famosa stringa, e l'altro che oltre a questo crea un paio di tabelle temporanee e fa il dump del filesystem del SQL su tabella, che poi restituisce in output.
Il secondo problema si può facilmente risolvere configurando in maniera coerente gli accessi al database (niente sa, niente dbowner, niente di niente :D).
Per il primo problema, invece, l'unica soluzione reale è utilizzare stored procedures con parameters: una soluzione che nel 1999/2000 utilizzavano in due e che ora è un must-have.
Purtroppo riscrivere un intero sito utilizzando stored procedures può non essere semplicissimo, soprattutto in caso di ecommerce o applicativi complessi.
In questi casi una soluzione possibile è controllare ogni imput utilizzando regular expression (tipo regEx.Pattern = "[^0-9a-zA-Z]" per filtrare qualsiasi cosa non sia un numero o una lettera) o una lista di "bad words", inserendo per esempio "CAST", "VARCHAR", etc. Purtroppo, si corre il rischio di filtrare anche contenuti corretti, soprattutto in caso di CMS... li bisogna controllare di volta in volta il singolo caso, rimboccarsi le maniche e... convincere il cliente a migrare il sito del 1999 in ASP.NET!!!!! :D
P.S.: Si, ho scritto tutto questo perchè il piu vecchio applicativo residente sui miei server è stato ovviamente attaccato! Se qualcuno avesse dei problemi a ripulire il DB, mi sono fatto una consolle application che con sprezzo di select si occupa di girarsi tutti i campi e rimettere a posto le cose. Se a qualcuno serve, mi contatti: ovviamente non mi prendo responsabilità :P