Share via


Cenni preliminari sugli attacchi tramite script

Aggiornamento: novembre 2007

Dal punto di vista di un browser, una pagina Web è null'altro che una lunga stringa di caratteri. Il browser elabora la stringa in sequenza, visualizzando alcuni caratteri e interpretandone altri, quali <b> e <script>, in base a determinate regole. Se un utente malintenzionato inserisce alcuni caratteri speciali in una pagina, il browser non potrà distinguerli dagli altri e li elaborerà come facenti parte della pagina.

Un semplice attacco tramite script potrebbe agire come indicato di seguito. Se un'applicazione consente agli utenti di inviare commenti sui film più recenti affinché possano essere letti da altri utenti, le fasi dell'attacco potrebbero essere queste:

  1. L'applicazione visualizza un form in cui gli utenti immettono i propri commenti. L'utente malintenzionato scrive un commento che include un blocco <script>.

  2. Il form viene inviato e il commento dell'utente malintenzionato viene memorizzato in un database.

  3. Un altro utente visita il sito. I commenti letti dal database vengono inseriti in una pagina. Il blocco <script> dell'utente malintenzionato viene scritto nella pagina come se fosse un commento di testo.

  4. Quando il browser del secondo utente visualizza la pagina, viene eseguito il blocco <script>.

Gli utenti malintenzionati possono sferrare attacchi tramite script in altri modi. Il buon esito della maggior parte degli attacchi tramite script richiede comunque che l'applicazione accetti l'input dannoso e lo inserisca in una pagina, da cui verrà eseguito da un browser. Il danno potenziale di un simile attacco dipende dallo script che viene eseguito. Può essere banale, come un fastidioso messaggio popup che viene aperto dal browser. In alternativa può provocare danni consistenti, violando i cookie e gli input utente (ad esempio una password) o, se la protezione Internet è bassa, eseguendo codice nativo sul computer dell'utente.

Per informazioni sulla prevenzione degli attacchi tramite script, vedere Procedura: proteggere da attacchi tramite script in un'applicazione Web applicando alle stringhe la codifica HTML.

Nota:

ASP.NET consente di fronteggiare gli attacchi tramite script passati come URL mediante la verifica di stringhe potenzialmente pericolose quali "<!", "</" e "<?".

Attacchi tramite istruzioni SQL

Una variante degli attacchi tramite script è quella che mira all'esecuzione di istruzioni SQL dannose. Le applicazioni risultano vulnerabili a questo tipo di attacchi quando chiedono all'utente informazioni che vengono poi concatenate in una stringa che costituisce l'istruzione SQL. È ad esempio possibile che un'applicazione chieda il nome di un cliente con l'intento di eseguire un'istruzione come quella seguente:

"Select * From Customers where CustomerName = " & txtCustomerName.Value

Un utente malintenzionato che dispone di qualche informazione sul database potrebbe però immettere nella casella di testo un'istruzione SQL incorporata insieme al nome del cliente, affinché venga composta un'istruzione simile alla seguente:

Select * From Customers Where CustomerName = 'a' Delete From Customers Where CustomerName > ''

L'esecuzione della query comprometterà il database.

Protezione dagli attacchi tramite script

La prima difesa contro gli attacchi tramite script consiste nel non considerare mai attendibili le informazioni provenienti da un utente. Si parta dal presupposto che ogni informazione inviata all'applicazione da un browser può contenere script dannosi.

Analogamente, ogni volta che si scrive una stringa in una pagina, occorre considerare che la stringa potrebbe contenere script dannosi a meno che la stringa non sia stata creata a livello di codice dall'applicazione stessa. Quando ad esempio si leggono stringhe da un database, occorre considerare che queste potrebbero contenere script dannosi. Gli sviluppatori più accorti diffideranno anche dei propri stessi database, per l'eventualità che un utente malintenzionato sia riuscito ad alterarne il contenuto.

Con ASP.NET vengono fornite diverse soluzioni per la protezione contro gli attacchi tramite script:

  • ASP.NET esegue la convalida delle richieste in base alle variabili di stringa di query, alle variabili di form e ai valori di cookie. Per impostazione predefinita, se l'oggetto Request corrente contiene elementi con codifica HTML o determinati caratteri HTML (quali &#151; per il trattino lungo), viene generato un errore dal framework di pagina ASP.NET.

  • Se si desidera visualizzare nell'applicazione stringhe che non possono essere considerate attendibili, applicarvi la codifica HTML. quando vengono scritte in una risposta. Con la codifica, il tag <b> diventa ad esempio &lt;b&gt;. È possibile adottare tale codifica quando le stringhe da visualizzare provengono da un database il cui contenuto non può essere considerato completamente attendibile.

  • Se si desidera consentire all'utente l'utilizzo di elementi HTML (ad esempio alcune istruzioni di formattazione), codificare l'HTML sul client prima che venga inviato al server. Per ulteriori informazioni, vedere la classe Procedura: proteggere da attacchi tramite script in un'applicazione Web applicando alle stringhe la codifica HTML.

  • Ai fini della protezione dagli attacchi tramite istruzioni SQL, non creare mai query SQL prodotte dalla concatenazione di stringhe. Utilizzare invece una query con parametri e assegnare l'input utente a oggetti Parameter. Per informazioni dettagliate, vedere Parametri dei comandi degli adattatori dati.

  • Convalidare sempre l'input del form in base a un insieme di valori previsti e alla formattazione e al tipo di stringa. Ad esempio, se si prevede che una variabile specifica del form sia un numero intero, utilizzare il metodo Int32.TryParse per verificare che il valore sia davvero un numero intero e la verifica dell'intervallo per assicurarsi che il valore rientri in un intervallo valido.

Vedere anche

Attività

Procedura: proteggere da attacchi tramite script in un'applicazione Web applicando alle stringhe la codifica HTML

Concetti

Cenni preliminari sui pericoli di protezione a cui sono esposte le applicazioni Web

Suggerimenti di base sulla protezione delle applicazioni Web