Analogamente alla precedente release 3.5, ASP.NET 4.0 non rappresenta una versione rivoluzionaria. Molte funzionalità che sono state aggiunte vanno semplicemente ad arricchire o a completare l'insieme delle possibilità offerte da ASP.NET per lo sviluppo di applicazioni web già nelle versioni precedenti. Molte delle novità sono già state elencate nell'articolo introduttivo pubblicato in occasione dello speciale dedicato al lancio di Visual Studio 2010. Tuttavia, come è prevedibile, le novità non si fermano a quelle incluse nell'articolo menzionato. Ne esistono numerose altre, di cui andremo ad elencare le principali, prendendo come riferimento i contenuti inclusi nel libro "ASP.NET 4.0 in C# e VB".

Redirect permanente delle pagine

(dal capitolo 8, pag. 145)

Esistono diverse versioni di Redirect per la classe HttpResponse; tra queste compare RedirectPermanent (NdR).

• Redirect: redirige una richiesta su un'altra pagina utilizzando lo status 302.
• RedirectPermanent: redirige una richiesta su un'altra pagina utilizzando lo status 301.
• RedirectToRoute: redirige una richiesta su un'altra pagina in funzione delle regole di routing.

Compressione della sessione

(dal capitolo 17, pag. 364)

Nella configurazione della sessione, con ASP.NET 4.0 abbiamo a disposizione il parametro enableCompression. Questo parametro può veramente fare la differenza, in quanto specifica al motore di ASP.NET di comprimere i dati in formato gzip prima di inviarli in rete verso lo storage esterno (servizio o SQL Server). Se, da un lato, con quest'impostazione carichiamo maggiormente la CPU per poter effettuare la compressione, quando salviamo i dati, e la decompressione, quando li recuperiamo, dall'altro otteniamo un notevole risparmio di memoria, nel caso di servizio esterno, e un notevole risparmio di dati (quindi pagine), quando usiamo SQL Server o un database qualsiasi.

Estendibilità della validazione delle richieste

(dal capitolo 21, pagg. 441-442)

Per evitare i problemi di sicurezza legati al cross-site scripting, viene in aiuto ASP.NET, che valida ogni richiesta quando accediamo alle proprietà QueryString, Form e Cookies della classe HttpRequest, cercando l'eventualemarkup, potenzialmente dannoso, nei vari campi. Se la ricerca avrà esito positivo, verrà sollevata un'eccezione di tipo HttpRequestValidationException, che fermerà l'esecuzione della richiesta.

Possiamo attivare o disattivare questo controllo agendo sull'attributo ValidateRequest della direttiva @Page. Il valore predefinito è true, perciò possiamo dire che la maggior parte dei pericoli, basando la nostra applicazione su ASP.NET, saranno evitati. Tale flag funziona solo se si attiva la modalità system.web/httpRuntime/@requestValidationMode a una versione inferiore alla 4.0. Il comportamento predefinito prevede infatti che tutte le richieste, anche non verso .aspx, vengano controllate all'inizio di ogni richiesta. Se vogliamo consentire a un utente che, per una specifica pagina, possa inserire del markup, dobbiamo provvedere alla creazione di un validator personalizzato.

Nell'esempio 21.7 possiamo vedere come crearne uno che erediti dal validatore predefinito RequestValidator e inibisca il controllo nel caso la pagina si chiami xss.aspx e sia richiesto il controllo del contenuto della form. Resteranno quindi attivi i controlli sull'URI, gli Header e i Cookie.

Public Class CustomValidator
  Inherits RequestValidator
  Protected Overloads Overrides Function IsValidRequestString(ByVal context As HttpContext, ByVal value As String, ByVal requestValidationSource As RequestValidationSource, ByVal collectionKey As String, ByRef validationFailureIndex As Integer) As Boolean
    ' Alla pagina xss.aspx è consentito accedere
    If requestValidationSource = RequestValidationSource.Form AndAlso context.Request.Path.IndexOf("xss.aspx", StringComparison.CurrentCultureIgnoreCase) >= 0 Then
      validationFailureIndex = 0
      Return True
    End If
    Return MyBase.IsValidRequestString(context, value, requestValidationSource, collectionKey, validationFailureIndex)
  End Function
End Class

public class CustomValidator : RequestValidator
{
  protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
  {
    // Alla pagina xss.aspx è consentito accedere
    if (requestValidationSource == RequestValidationSource.Form && context.Request.Path.IndexOf("xss.aspx", StringComparison.CurrentCultureIgnoreCase) >= 0)
    {
      validationFailureIndex = 0;
      return true;
    }
    return base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
  }
}

Per usare poi il nostro validatore personalizzato, dobbiamo impostarlo nel web.config attraverso la sezione httpRuntime.

<system.web>
  <httpRuntime requestValidationType="AppCode.CustomValidator" />
</system.web>

Ad ogni modo, anche ponendo in essere questa misura non siamo al riparo da attacchi, perché non è detto che le informazioni che mostriamo nella pagina siano provenienti da una precedente validazione. Per questo motivo consigliamo di codificare sempre ciò che inseriamo nella pagina. A tale scopo la classe HttpUtility dispone dei metodi statici HtmlEncode, HtmlAttributeEncode e UrlEncode per codificare in HTML e in URI una stringa, così da evitare che il browser interpreti un eventuale markup. Il risultato sarà che, a fronte di un ipotetico input come <font size="40">Testo 2</font>, otteniamo la stringa &lt;font size=&quot;40&quot;&gt;Testo 2&lt;/font&gt;, non interpretabile dal browser, che la visualizzerà in maniera corretta. Il codice 21.9 mostra come utilizzare questi metodi per codificare le stringhe a seconda delle situazioni in cui dobbiamo inserirle: sono ovviamente utilizzabili anche nel code behind.

<%#HttpUtility.HtmlEncode(Container.DataItem.ToString()) %>
<%:Container.DataItem %>

<img src="img-<%#HttpUtility.HtmlAttributeEncode(Container.DataItem.ToString()) %>.gif" />
<a href="newpage.aspx?data=<%#HttpUtility.UrlEncode(Container.DataItem.ToString())%>">Link</a>

Da notare comunque che controlli come LoginName, PasswordRecovery, SiteMapPath, BoundField e Menu effettuano già automaticamente la codifica, evitando questo genere di rischio.