Premetto: è un bug pericoloso, ma i fattori mitiganti sono talmente tanti che devi proprio scegliere di essere esposto a questo richiscio.
In primis basta ed avanza IIS 6, che fa un lavoro di canonicalization sull'URL, trasformando tutto nell'equivalente carattere corrispondente. E se proprio siete ancora antichi ed avete deciso di non usare il miglior web server che esiste sulla faccia del pianeta (cioè state ancora usando IIS 5 ;) allora è arrivato il momento di far gestire i vostri server da qualcuno che prende sul serio la sicurezza. Perchè non installare, in 4 anni o quasi che esiste, UrlScan, è volere farsi del male. Spesso i bug sono pericolosi perchè li possiamo solo subire, senza poter essere proattivi, tante altre volte sfruttano solo errori di configurazione o mancanza di cultura della sicurezza. Ogni tanto rileggo questo articolo, per certi versi un po' estremo, e vedo che nonostante siano passati quasi due anni, più che migliorare siamo sullo stazionario.
Eppure avrò sentito non so quante volte la brava gente del dev team di ASP.NET parlare di canonicalization ed ora ci sono caduti :(
La soluzione migliore, comunque, quella che uso e che consiglio di utilizzare è un sistema di autorizzazione fatto ad hoc. Ultimamente mi è presa la mania del pattern Front Controller ed in questo ambito è davvero semplice sfruttare direttamente un controllo degli accessi, senza appoggiarsi ad ASP.NET (che in fin dei conti fa la stessa identica cosa).
Va comunque bene sfruttare il meccanismo di ASP.NET, che è comodissimo, ma se nelle pagina imparassimo a fare User.IsInRole(ruolo), in maniera programmatica oltre che sfruttando l'HttpModule UrlAuthorization di ASP.NET, forse vivremmo tutti più felici. E' una ripetizione, certamente, ma la sicurezza è anche e soprattutto ripetere più e più volte gli stessi, a volte noiosi, controlli. Perchè il software lo scrivono gli esseri umani e finchè sarà così, gli errori ci saranno sempre. L'importante è farsi trovare pronti ed applicare le patch (ufficiali o auto prodotte) a mano. E cercare di pensare sempre oltre le apparenze. Scrivere codice è un'arte e come tale richiede un po' di fantasia, oltre che tantissima buona tecnica!
Ho visto che ne hanno parlato un po' tutti in giro, ognuno dicendo la sua... Non lo faccio anch'io perchè sarebbe un ripetere quello che hai detto tu e che hanno detto gli altri.
Voglio solamente sottolineare, a mio avviso, l'importanza di scrivere codice ed inserire meccanismi ridondanti nelle applicazioni quando si parla di sicurezza. Credo che la soluzione per fare sonni relativamente tranquilli, al di là dell'installazione delle patch di sicurezza, sia quella (come dici tu) di pensare ben oltre le apparenze.
Un codice robusto è un codice che può dare buone garanzie sulla sicurezza. Pensare in grande aiuta a realizzare applicazioni robuste e sicure. Se non altro, si rende la vita difficile a chi cerca di sfruttare eventuali exploit e/o bachi.
Ciao, Ricky.
Sono pienamente d'accordo sia con Daniele sia con rickyvr. Ma voglio solo aggiungere un mio pensiero: ma non è allarmismo esagerato quello che si legge tra i vari sviluppatori nei vari blog e/o pagine in rete?
Mi spiego meglio: ho dato un'occhiata in giro ai vari siti e server che ospitano pagine asp.net e che utilizzano l'autenticazione Forms. Non ne ho trovato uno che venisse bucato da quel trucco del "\" o "%5C". E sto parlando anche di server con servizi di hosting economici - mi piacerebbe sapere se anche Aruba è protetto, purtroppo non ho potuto accertarmene. Ma forse la mia è stata solo fortuna!
Che forse il problema di sicurezza del framework sia protetto da altre strutture di sicurezza dagli amministratori dei server che, senza tanti problemi, per la sicurezza interna, avevano già installato da tempo i vari tool come UrlScan?
Che forse il tanto conclamato bug esista nella maggioranza dei casi solo sui computer degli sviluppatori?
Siamo sicuri che IIS 6.0 è immune?
Sul sito Microsoft è riportato:
Software Affected
? ASP.NET running on Windows 2000
? ASP.NET running on Windows 2000 Server
? ASP.NET running on Windows XP Professional
? ASP.NET running on Windows Server 2003
Come faccio a testare la mia applicazione per questa vulnerabilità?
Qualcuno ha provato ad installare il
Microsoft ASP.NET ValidatePath Module?
Funziona?
Ciao.
lucascat ha scritto:
Siamo sicuri che IIS 6.0 è immune?
quasi quasi mi offendo per questa domanda
btw, ASP.NET è soggetto a questo problema sulle piattaforme elencate, perchè ASP.NET non è detto che giri in IIS (vedi cassini). se però usi IIS 6 o IIS 5 + UrlScan, allora sei immune perchè ad ASP.NET non arriva l'URL "corretto", bloccato da IIS 6 o UrlScan.
Come faccio a testare la mia applicazione per questa vulnerabilità?
fai una pagina protetta con Forms Auth e ci metti \\ nel Path, con Mozilla. se te la lascia vedere, allora non sei immune.
Qualcuno ha provato ad installare il
Microsoft ASP.NET ValidatePath Module?
non contiene nient'altro che il codice che è menzionato nella pagina, compilato e con un installer che lo registra in GAC e modifica il machine.config.
Come faccio a testare la mia applicazione per questa vulnerabilità?
fai una pagina protetta con Forms Auth e ci metti \\ nel Path, con Mozilla. se te la lascia vedere, allora non sei immune.
Non ho capito. Dove devo mettere \\ ?
nell'url.
anzichè usare http://sito/path/pagina.aspx, usa http://sito/path\\pagina.aspx.
se usi IIS 6 o IIS 5 + UrlScan saresti dovuto stare tranquillo a priori
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
Daniele Bochicchio