Sicurezza e input utente

I dati utente, che sono qualsiasi tipo di input (dati di una richiesta Web o un URL, l'input ai controlli di un'applicazione Microsoft Windows Form e così via), possono influire negativamente sul codice perché spesso tali dati vengono usati direttamente come parametri per chiamare altro codice. Questa situazione è analoga a codice dannoso che chiama il codice con parametri strani e devono essere prese le stesse precauzioni. L'input dell'utente è in realtà più difficile da rendere sicuro perché non esiste alcun stack frame per tracciare la presenza dei dati potenzialmente non attendibili.

Questi sono tra i bug di sicurezza più sottili e difficili da trovare perché, anche se possono esistere nel codice apparentemente non correlato alla sicurezza, sono un gateway per passare dati non corretti ad altro codice. Per cercare questi bug, seguire qualsiasi tipo di dati di input, immaginare l'intervallo di valori possibili e valutare se il codice che visualizza questi dati può gestire tutti questi casi. È possibile correggere questi bug tramite il controllo dell'intervallo e rifiutare qualsiasi input che il codice non può gestire.

Di seguito sono riportate alcune considerazioni importanti relative ai dati utente:

• Tutti i dati utente in una risposta del server vengono eseguiti nel contesto del sito del server nel client. Se il server Web accetta i dati utente e lo inserisce nella pagina Web restituita, può, ad esempio, includere un <script> tag ed eseguirlo come se dal server.

• Tenere presente che il client può richiedere qualsiasi URL.

• Prendere in considerazione percorsi complessi o non validi:

  • .. \ , percorsi estremamente lunghi.

  • Uso dei caratteri sostitutivi (*)

  • Espansione del token (%token%).

  • Strane forme di percorsi con un significato speciale.

  • Nomi di flusso alternativi del file system, ad esempio filename::$DATA.

  • Versioni brevi dei nomi di file, ad longfi~1 esempio per longfilename.

• Tenere presente che Eval(userdata) può eseguire qualsiasi operazione.

• Fare attenzione all'associazione tardiva a un nome che include alcuni dati utente.

• Se si gestiscono dati Web, considerare le varie forme di escape consentite, tra cui:

  • Escape esadecimali (%nn).

  • Escape Unicode (%nnn).

  • Escape UTF-8 eccessivamente lunghe (%nn%nn).

  • Le doppie sequenze di escape (%nn diventa %mmnn, dove %mm è la sequenza di escape per '%').

• Fare attenzione ai nomi utente che potrebbero avere più di un formato canonico. Ad esempio, è spesso possibile usare il modulo MYDOMAIN\username o il modulo username@mydomain.example.com.

Vedere anche

• linee guida per la codifica sicura
• ASP.NET Core Security