Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
| 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:
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.
|
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
Aprire il |
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 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 |
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.