Condividi tramite


Frame di sicurezza: Gestione delle eccezioni | Mitigazioni

Prodotto o servizio Articolo
WCF
Web API
Applicazione Web

WCF- Non includere il nodo serviceDebug nel file di configurazione

Titolo dettagli
Componente WCF
Fase SDL Costruire
Tecnologie applicabili Generico, NET Framework 3
Attributi N/A
References MSDN, Fortify Kingdom
Steps Windows servizi WCF (Communication Framework) possono essere configurati per esporre informazioni di debug. Le informazioni di debug non devono essere usate negli ambienti di produzione. Il <serviceDebug> tag definisce se la funzionalità di informazioni di debug è abilitata per un servizio WCF. Se l'attributo includeExceptionDetailInFaults è impostato su true, le informazioni sulle eccezioni dell'applicazione verranno restituite ai client. Gli utenti malintenzionati possono sfruttare le informazioni aggiuntive ottenute dall'output di debug per montare gli attacchi mirati al framework, al database o ad altre risorse usate dall'applicazione.

Esempio

Il file di configurazione seguente include il <serviceDebug> tag :

<configuration> 
<system.serviceModel> 
<behaviors> 
<serviceBehaviors> 
<behavior name=""MyServiceBehavior""> 
<serviceDebug includeExceptionDetailInFaults=""True"" httpHelpPageEnabled=""True""/> 
... 

Disabilitare le informazioni di debug nel servizio. A tale scopo, è possibile rimuovere il <serviceDebug> tag dal file di configurazione dell'applicazione.

WCF- Non includere il nodo serviceMetadata nel file di configurazione

Titolo dettagli
Componente WCF
Fase SDL Costruire
Tecnologie applicabili Elemento generico
Attributi Generico, NET Framework 3
References MSDN, Fortify Kingdom
Steps L'esposizione pubblica di informazioni su un servizio può fornire agli utenti malintenzionati informazioni utili su come sfruttare il servizio. Il <serviceMetadata> tag abilita la funzionalità di pubblicazione dei metadati. I metadati del servizio possono contenere informazioni riservate che non devono essere accessibili pubblicamente. Almeno, consentire agli utenti attendibili di accedere ai metadati e assicurarsi che le informazioni non necessarie non siano esposte. Ancora meglio, disabilitare completamente la possibilità di pubblicare i metadati. Una configurazione WCF sicura non conterrà il <serviceMetadata> tag .

Assicurarsi che la gestione corretta delle eccezioni venga eseguita in ASP.NET Web API

Titolo dettagli
Componente API per il Web
Fase SDL Costruire
Tecnologie applicabili MVC 5, MVC 6
Attributi N/A
References Exception Handling in ASP.NET Web API, Model Validation in ASP.NET Web API
Steps Per impostazione predefinita, la maggior parte delle eccezioni non rilevate in ASP.NET Web API viene convertita in una risposta HTTP con codice di stato 500, Internal Server Error

Esempio

Per controllare il codice di stato restituito dall'API, HttpResponseException è possibile usare come illustrato di seguito:

public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        throw new HttpResponseException(HttpStatusCode.NotFound);
    }
    return item;
}

Esempio

Per un ulteriore controllo sulla risposta all'eccezione, la HttpResponseMessage classe può essere usata come illustrato di seguito:

public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
        {
            Content = new StringContent(string.Format("No product with ID = {0}", id)),
            ReasonPhrase = "Product ID Not Found"
        }
        throw new HttpResponseException(resp);
    }
    return item;
}

Per intercettare eccezioni non gestite che non sono di tipo HttpResponseException, è possibile usare filtri eccezioni. I filtri di eccezione implementano l'interfaccia System.Web.Http.Filters.IExceptionFilter. Il modo più semplice per scrivere un filtro di eccezione consiste nel derivare dalla System.Web.Http.Filters.ExceptionFilterAttribute classe ed eseguire l'override del metodo OnException.

Esempio

Ecco un filtro che converte le NotImplementedException eccezioni in codice 501, Not Implementeddi stato HTTP:

namespace ProductStore.Filters
{
    using System;
    using System.Net;
    using System.Net.Http;
    using System.Web.Http.Filters;

    public class NotImplExceptionFilterAttribute : ExceptionFilterAttribute 
    {
        public override void OnException(HttpActionExecutedContext context)
        {
            if (context.Exception is NotImplementedException)
            {
                context.Response = new HttpResponseMessage(HttpStatusCode.NotImplemented);
            }
        }
    }
}

Esistono diversi modi per registrare un filtro eccezioni api Web:

  • Tramite un'azione
  • Tramite un controller
  • Globalmente

Esempio

Per applicare il filtro a un'azione specifica, aggiungere il filtro come attributo all'azione:

public class ProductsController : ApiController
{
    [NotImplExceptionFilter]
    public Contact GetContact(int id)
    {
        throw new NotImplementedException("This method is not implemented");
    }
}

Esempio

Per applicare il filtro a tutte le azioni di un controlleroggetto , aggiungere il filtro come attributo alla controller classe :

[NotImplExceptionFilter]
public class ProductsController : ApiController
{
    // ...
}

Esempio

Per applicare il filtro a livello globale a tutti i controller API Web, aggiungere un'istanza del filtro alla GlobalConfiguration.Configuration.Filters raccolta. I filtri di eccezione in questa raccolta si applicano a qualsiasi azione del controller dell'API Web.

GlobalConfiguration.Configuration.Filters.Add(
    new ProductStore.NotImplExceptionFilterAttribute());

Esempio

Per la convalida del modello, lo stato del modello può essere passato al metodo CreateErrorResponse, come illustrato di seguito:

public HttpResponseMessage PostProduct(Product item)
{
    if (!ModelState.IsValid)
    {
        return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
    }
    // Implementation not shown...
}

Controllare i collegamenti nella sezione riferimenti per altri dettagli sulla gestione eccezionale e la convalida del modello in ASP.NET Web API

Non esporre i dettagli di sicurezza nei messaggi di errore

Titolo dettagli
Componente Applicazione Web
Fase SDL Costruire
Tecnologie applicabili Elemento generico
Attributi N/A
References N/A
Steps

I messaggi di errore generici vengono forniti direttamente all'utente senza includere i dati sensibili dell'applicazione. Esempi di dati sensibili includono:

  • Nomi dei server
  • Stringhe di connessione
  • Nomi utente
  • Passwords
  • Procedure SQL
  • Dettagli degli errori SQL dinamici
  • traccia dello stack e righe di codice
  • Variabili archiviate in memoria
  • Percorsi di unità e cartelle
  • Punti di installazione dell'applicazione
  • Impostazioni di configurazione dell'host
  • Altri dettagli dell'applicazione interna

Intercettare tutti gli errori all'interno di un'applicazione e fornire messaggi di errore generici, nonché abilitare errori personalizzati all'interno di IIS consente di evitare la divulgazione di informazioni. Il database SQL Server e la gestione delle eccezioni in .NET, insieme ad altre architetture di gestione degli errori, sono particolarmente verbose ed estremamente utili per un utente malintenzionato che analizza il profilo dell'applicazione. Non visualizzare direttamente il contenuto di una classe derivata dalla classe exception .NET e assicurarsi di disporre di una gestione corretta delle eccezioni in modo che un'eccezione imprevista non venga generata inavvertitamente direttamente all'utente.

  • Fornire messaggi di errore generici direttamente all'utente che astraggono dettagli specifici trovati direttamente nel messaggio di eccezione/errore
  • Non visualizzare il contenuto di una classe di eccezione .NET direttamente all'utente
  • Intercettare tutti i messaggi di errore e, se appropriato, informare l'utente tramite un messaggio di errore generico inviato al client dell'applicazione
  • Non esporre il contenuto della classe Exception direttamente all'utente, in particolare il valore restituito da .ToString()o i valori delle proprietà Message o StackTrace. Registrare in modo sicuro queste informazioni e visualizzare un messaggio più innocuo all'utente

Implementare la pagina di gestione degli errori predefinita

Titolo dettagli
Componente Applicazione Web
Fase SDL Costruire
Tecnologie applicabili Elemento generico
Attributi N/A
References Modifica finestra di dialogo Impostazioni pagine di errore di ASP.NET
Steps

Quando un'applicazione ASP.NET ha esito negativo e causa un errore http/1.x 500 interno del server o una configurazione di funzionalità (ad esempio Filtro richieste) impedisce la visualizzazione di una pagina, verrà generato un messaggio di errore. Gli amministratori possono scegliere se l'applicazione deve visualizzare un messaggio descrittivo al client, un messaggio di errore dettagliato al client o un messaggio di errore dettagliato solo in localhost. Il <customErrors> tag nella web.config ha tre modalità:

  • On: Specifica che gli errori personalizzati sono abilitati. Se non viene specificato alcun attributo defaultRedirect, gli utenti visualizzano un errore generico. Gli errori personalizzati vengono visualizzati nei client remoti e nell'host locale
  • Disattivato: Specifica che gli errori personalizzati sono disabilitati. Gli errori di ASP.NET dettagliati vengono visualizzati ai client remoti e all'host locale
  • RemoteOnly: Specifica che gli errori personalizzati vengono visualizzati solo ai client remoti e che ASP.NET errori vengono visualizzati nell'host locale. Questo è il valore predefinito

Aprire il web.config file per l'applicazione/sito e assicurarsi che il tag abbia <customErrors mode="RemoteOnly" /> o <customErrors mode="On" /> definito.

Impostare il metodo di distribuzione per la vendita al dettaglio in IIS

Titolo dettagli
Componente Applicazione Web
Fase SDL Distribuzione
Tecnologie applicabili Elemento generico
Attributi N/A
References Elemento deployment (schema impostazioni ASP.NET)
Steps

L'opzione <deployment retail> è destinata all'uso da parte dei server IIS di produzione. Questa opzione viene usata per consentire alle applicazioni di eseguire con le migliori prestazioni possibili e le perdite di informazioni di sicurezza meno possibili disabilitando la capacità dell'applicazione di generare l'output di traccia in una pagina, disabilitando la possibilità di visualizzare messaggi di errore dettagliati agli utenti finali e disabilitando l'opzione di debug.

Spesso, gli interruttori e le opzioni destinati agli sviluppatori, come il tracing delle richieste non riuscite e il debug, vengono abilitati durante lo sviluppo attivo. È consigliabile impostare il metodo di distribuzione in qualsiasi server di produzione per la vendita al dettaglio. aprire il file machine.config e assicurarsi che <deployment retail="true" /> rimanga impostato su true.

Le eccezioni devono avere esito negativo in modo sicuro

Titolo dettagli
Componente Applicazione Web
Fase SDL Costruire
Tecnologie applicabili Elemento generico
Attributi N/A
References Esito negativo in modo sicuro
Steps L'applicazione dovrebbe fallire in modo sicuro. Qualsiasi metodo che restituisce un valore booleano, in base al quale viene presa una determinata decisione, deve avere un blocco di eccezioni creato con attenzione. Ci sono molti errori logici a causa dei problemi di sicurezza che si verificano, quando il blocco di eccezioni viene scritto senza attenzione.

Esempio

        public static bool ValidateDomain(string pathToValidate, Uri currentUrl)
        {
            try
            {
                if (!string.IsNullOrWhiteSpace(pathToValidate))
                {
                    var domain = RetrieveDomain(currentUrl);
                    var replyPath = new Uri(pathToValidate);
                    var replyDomain = RetrieveDomain(replyPath);

                    if (string.Compare(domain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
                    {
                        //// Adding additional check to enable CMS urls if they are not hosted on same domain.
                        if (!string.IsNullOrWhiteSpace(Utilities.CmsBase))
                        {
                            var cmsDomain = RetrieveDomain(new Uri(Utilities.Base.Trim()));
                            if (string.Compare(cmDomain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
                            {
                                return false;
                            }
                            else
                            {
                                return true;
                            }
                        }

                        return false;
                    }
                }

                return true;
            }
            catch (UriFormatException ex)
            {
                LogHelper.LogException("Utilities:ValidateDomain", ex);
                return true;
            }
        }

Il metodo precedente restituirà sempre True, se si verifica un'eccezione. Se l'utente finale fornisce un URL in formato non valido, che il browser rispetta, ma il Uri() costruttore no, verrà lanciata un'eccezione e la vittima verrà indirizzata all'URL valido ma in formato non valido.