Realizzare applicazioni ASP.NET sicure - Prima parte
Ultimamente si sente sempre più spesso parlare di "sicurezza delle applicazioni". Tutti gli esperti del settore sono concordi nel ritenere che la sicurezza non debba essere considerata un accessorio, un optional, bensì una componente fondamentale e imprescindibile dello sviluppo, al pari di un qualunque altro requisito funzionale:
"Security is part of getting the job done. It's part of the process."
("La sicurezza è parte integrante del lavoro, è parte del processo.")
Michael Howard
Senior security program manager, Microsoft
Se questo è vero per qualunque prodotto software, lo è ancora di più in ambito Web, dove la sicurezza è una vera e propria necessità, determinata dalla natura stessa di Internet, che rende disponibili le applicazioni - e di conseguenza attaccabili - ad un grandissimo numero di utenti.
Troppo spesso non si dà peso a questo fattore e quando ci si accorge di avere un problema, è ormai troppo tardi. In questo articolo suddiviso in due parti verranno esaminate le cause di errore più comuni e gli accorgimenti da adottare per limitare al minimo la vulnerabilità di un'applicazione ASP.NET.
Protezione da Cross-Site Scripting (XSS)
Cross-Site Scripting, noto anche con l'acronimo XSS (non CSS che indica invece Cascading Style Sheet), è una vulnerabilità tipica delle applicazioni Web, per cui un utente malintenzionato è in grado di iniettare codice JavaScript, solitamente attraverso forms o querystring, così da aggirare le policy di sicurezza dei client o dell'applicazione stessa.
Consideriamo ad esempio una pagina Web in cui i visitatori possano inserire un commento, come un guestbook:
<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
protected void btnAddMessage_Click(object sender, EventArgs e)
{
string msg = txtMessage.Text;
// omissis: salvataggio del testo [msg] nel database
// omissis: visualizzazione tramite databind
// dell'archivio dei messaggi ricevuti;
// a scopo dimostrativo viene visualizzato solo il messaggio ricevuto:
lblViewMessage.Text = msg;
}
</script>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Guestbook</title>
</head>
<body>
<form id="frmNewMessage" runat="server">
<div>
<h1>Invia un messaggio</h1>
<asp:TextBox ID="txtMessage" runat="server" TextMode="MultiLine" />
<asp:Button ID="btnAddMessage" runat="server" Text="Invia" OnClick="btnAddMessage_Click" />
<hr />
<asp:Label ID="lblViewMessage" runat="server" />
</div>
</form>
</body>
</html>
Apparentemente questa pagina non presenta alcuna particolarità degna di nota: quando un utente digita un messaggio (ad esempio "Ciao mondo!") e preme il tasto "Invia" la pagina viene ricaricata mostrando sotto il form di inserimento un'etichetta che riporta esattamente il testo ricevuto (nell'utilizzo reale il testo verrà salvato in un database e la visualizzazione avverrà estraendo i record presenti; nell'esempio questa parte di codice è omessa).
Ora supponiamo di inserire nella casella di testo il seguente messaggio:
Ciao <b>mondo </b>!
In questo caso la pagina solleverà un'eccezione di tipo HttpRequestValidationException:
ASP.NET infatti rileva automaticamente la presenza di codice potenzialmente pericoloso e "protegge" la nostra applicazione.
Se però volessimo dare la possibilità ai visitatori di inviare commenti applicando della formattazione (ad esempio sostituendo la semplice casella di testo con un editor visuale di tipo WYSIWYG) dovremo disabilitare il meccanismo di controllo della richiesta di ASP.NET, impostando nella direttiva @Page:
<%@ Page Language="C#" ValidateRequest="false" %>
NOTA: sebbene sia possibile disabilitare la validazione delle richieste per l'intera applicazione tramite Web.config è consigliabile disabilitare la funzionalità solo per le pagine che richiedono specificatamente questa funzionalità.
A questo punto la nostra applicazione inizierà ad ammettere la formattazione inserita dall'utente, ma incominceranno anche i problemi di sicurezza.
Supponiamo infatti che un utente inserisca nella casella di testo:
<script>alert("Ciao mondo!");</script>
Il risultato sarebbe:
Lo script iniettato da un utente viene eseguito nel contesto della pagina ospite, con implicazioni sulla sicurezza e con un danno che potrà essere semplicemente fastidioso come nel caso di un "alert" o dell'apertura di una finestra pop-up, oppure decisamente più grave come il furto di cookie o di input degli utenti (ad esempio le credenziali di login).
Attenzione: Questo articolo contiene un allegato.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
