In risposta a questo commento di Pietro al mio post, ho deciso di scrivere un post dedicato. Il problema esposto da Pietro è che lui non riusciva a passare un parametro, criptato con l'algoritmo Rijndael, ad una nuova pagina ASP.NET, perchè subentrava in questa il ValidateRequest di ASP.NET, un controllo in grado di prevenire gli attacchi CSS (Cross-Site Scripting).

Giustamente ci si chiede, che nesso ci può essere tra una stringa criptata ed un attacco CSS? In teoria nessuno, in pratica, per uno strano caso, la stringa incriminata contiene del potenziale codice dannoso.

Infatti, esaminando il codice di errore, noto una strana coincidenza:

ON?!?

Diamo un'occhiata allo stack per scovare il metodo responsabile:

mmm...HttpRequest.ValidateString. Bene, con .NET Reflector alla mano cerchiamo di capire esattamente cosa non va. Localizzato il metodo ValidateString notiamo immediatamente una chiamata al metodo IsDangerousString, della classe interna CrossSiteScriptingValidation, che verifica la presenza, nella querystring, di alcuni caratteri particolari, come: '<', '&', 'o', 'O', 's', 'S', 'e', 'E'. Come non notare il quarto carattere?

Continuando nell'analisi del codice (troppo lungo per essere postato) notiamo che se viene incontrata una "O", viene eseguito il metodo CrossSiteScriptingValidation.IsDangerousOnString. Il metodo, del quale ho riportato solo le parti principali e di nostro interesse, verifica se alla "O" fa seguito una "N", ed infine, se la stringa termina con "=".

A questo punto, riguardando la nostra stringa iniziale, sembra proprio che le condizioni ci siano tutte!?! :O

Il perchè Microsoft ha inserito il controllo sulla parola "ON" credo sia legato alla volontà di evitare l'esecuzione di codice allo scatenarsi di eventi. Ad esempio, codice maligno potrebbe essere qualcosa del genere: http://www.mysite.com/mypage.aspx?id=blabla%22%20onMouseOver%3dcodice, che in una pagina potrebbe diventare, ad esempio: <A href="" onMouseOver=codice>. In grassetto sono riportate le caratteristiche controllate dal ValidateRequest.

A parte disabilitare il ValidateRequest (sconsigliato), l'unica soluzione pare quella di rimuovere il segno di uguale alla fine della stringa per poi ripristinarlo prima del decrypt.

[update] E' consigliato l'utilizzo di HttpUtility.UrlEncode per l'encoding della querystring prima della sua scrittura nella pagina, e successivamente HttpUtility.UrlDecode prima di leggere.

Soluzioni migliori?

powered by IMHO 1.2