ASP.NET Exploit: Sempre a proposito del tema caldo del weekend :-) ...
Smanettando un po' con il bug segnalato su SourceForge, ripreso da Andrea Saltarello e Lorenzo Barbieri e spiegato in maggior dettaglio da RoB, mi sono accorto di una cosa "simpatica" :-). Al di là del fatto che fa benissimo RoB a suggerire un Replace di tutte le occorrenze di %5C e di \ , perchè sfruttando questo bug un hacker potrebbe richiedere la URL "bucata" in diverse forme. Le seguenti sono infatti tutte URL valide:
http://localhost/DevLeap/ExploitASPNET%5C%5C%5CDefault.aspx
http://localhost/DevLeap/ExploitASPNET%5CDefault.aspx
http://localhost/DevLeap/ExploitASPNET%5C.%5CDefault.aspx
http://localhost/DevLeap/ExploitASPNET%5C../ExploitASPNET%5CDefault.aspx
http://localhost/DevLeap/ExploitASPNET%5C%2E%5CDefault.aspx
e ce ne sono molte altre (come è tipico dei problemi di canonicalization), semplicemente basta mettere una o più occorrenze di / o di %5C e il gioco è fatto, anche senza delle sotto-directory. Ma la cosa curiosa è che se utilizziamo la cookieless session () il problema (almeno stando alle prime prove che ho fatto) sembra svanire, apparentemente perchè il filtro ISAPI che rimappa la SessionID sul cookie virtuale, sembra riscrivere correttamente il path. Se infatti proviamo a scrivere una URL con il %5C al suo interno, con la cookieless session attivata, vedremo che il path richiesto ad ASP.NET risulta già corretto. Ad esempio la URL:
http://localhost/DevLeap/ExploitASPNET/(bbh4rvfebfvttlzt02lugn45)/%5CDefault.aspx
diventa:
http://localhost/DevLeap/ExploitASPNET/Default.ASPX
Infine per curiosità ho provato a riprodurre il problema anche su ASP.NET 2.0 (con Windows Server 2003 Standard Edition, ma usavo il Visual Web Developer Web Server di Whidbey ... quindi W2K3 c'entra poco) e ... usando la \ singola il problema non si presenta, usando %5C il problema non si presenta, ma utilizzando per esempio \\ il problema si presenta! :-(
Adesso faccio qualche altra prova ....
UPDATE: Pubblicando l'applicazione su IIS il problema non si presenta più, ma a questo punto - anche se non ho ancora approfondito la cosa - è probabile che il bug non si presenti per merito di IIS6 (che nasce imparato :-) !) e non per merito di ASP.NET 2.0 ... magari stasera (dopo l'uscita con la morosa e gli amici, riprenderò in mano il discorso per fare qualche altra prova).