Dela via

Säkerhetsram: Undantagshantering | Mitigations

  • Artikel
Produkt/tjänst Artikel
WCF
Webb-API
Webbprogram

WCF – Ta inte med serviceDebug-noden i konfigurationsfilen

Rubrik Information
Komponent WCF
SDL-fas Skapa
Tillämpliga tekniker Generic, NET Framework 3
Attribut Ej tillämpligt
Referenser MSDN, Fortify Kingdom
Steg WCF-tjänster (Windows Communication Framework) kan konfigureras för att exponera felsökningsinformation. Felsökningsinformation bör inte användas i produktionsmiljöer. Taggen <serviceDebug> definierar om funktionen för felsökningsinformation är aktiverad för en WCF-tjänst. Om attributet includeExceptionDetailInFaults är inställt på true returneras undantagsinformation från programmet till klienterna. Angripare kan utnyttja den ytterligare information som de får genom att felsöka utdata för att montera attacker riktade mot ramverket, databasen eller andra resurser som används av programmet.

Exempel

Följande konfigurationsfil innehåller taggen <serviceDebug> :

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

Inaktivera felsökningsinformation i tjänsten. Detta kan åstadkommas genom att ta bort taggen <serviceDebug> från programmets konfigurationsfil.

WCF – Inkludera inte serviceMetadata-noden i konfigurationsfilen

Rubrik Information
Komponent WCF
SDL-fas Skapa
Tillämpliga tekniker Allmänna
Attribut Generic, NET Framework 3
Referenser MSDN, Fortify Kingdom
Steg Att offentligt exponera information om en tjänst kan ge angripare värdefulla insikter om hur de kan utnyttja tjänsten. Taggen <serviceMetadata> aktiverar funktionen för metadatapublicering. Tjänstens metadata kan innehålla känslig information som inte ska vara offentligt tillgänglig. Tillåt som minst endast betrodda användare att komma åt metadata och se till att onödig information inte exponeras. Ännu bättre, helt inaktivera möjligheten att publicera metadata. En säker WCF-konfiguration innehåller inte taggen <serviceMetadata> .

Se till att rätt undantagshantering utförs i ASP.NET webb-API

Rubrik Information
Komponent Webb-API
SDL-fas Skapa
Tillämpliga tekniker MVC 5, MVC 6
Attribut Ej tillämpligt
Referenser Undantagshantering i ASP.NET webb-API, modellverifiering i ASP.NET webb-API
Steg Som standard översätts de flesta ohanterade undantag i ASP.NET webb-API till ett HTTP-svar med statuskod 500, Internal Server Error

Exempel

Du kan styra statuskoden som returneras av API:et enligt HttpResponseException nedan:

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

Exempel

För ytterligare kontroll av undantagssvaret HttpResponseMessage kan klassen användas enligt nedan:

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;
}

Om du vill fånga ohanterade undantag som inte är av typen HttpResponseExceptionkan du använda undantagsfilter. Undantagsfilter implementerar System.Web.Http.Filters.IExceptionFilter gränssnittet. Det enklaste sättet att skriva ett undantagsfilter är att härleda från System.Web.Http.Filters.ExceptionFilterAttribute klassen och åsidosätta metoden OnException.

Exempel

Här är ett filter som konverterar NotImplementedException undantag till HTTP-statuskod 501, Not Implemented:

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);
            }
        }
    }
}

Det finns flera sätt att registrera ett webb-API-undantagsfilter:

  • Efter åtgärd
  • Efter kontrollant
  • Globalt

Exempel

Om du vill tillämpa filtret på en viss åtgärd lägger du till filtret som ett attribut till åtgärden:

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

Exempel

Om du vill tillämpa filtret på alla åtgärder på en controllerlägger du till filtret som ett attribut i controller klassen :

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

Exempel

Om du vill tillämpa filtret globalt på alla webb-API-kontrollanter lägger du till en instans av filtret i GlobalConfiguration.Configuration.Filters samlingen. Undantagsfilter i den här samlingen gäller för alla webb-API-kontrollantåtgärder.

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

Exempel

För modellvalidering kan modelltillståndet skickas till metoden CreateErrorResponse enligt nedan:

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

Se länkarna i referensavsnittet för ytterligare information om exceptionell hantering och modellvalidering i ASP.NET Webb-API

Visa inte säkerhetsinformation i felmeddelanden

Rubrik Information
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmänna
Attribut Ej tillämpligt
Referenser Ej tillämpligt
Steg

Allmänna felmeddelanden tillhandahålls direkt till användaren utan att inkludera känsliga programdata. Exempel på känsliga data är:

  • Servernamn
  • Anslutningssträngar
  • Användarnamn
  • Lösenord
  • SQL-procedurer
  • Information om dynamiska SQL-fel
  • Stackspårning och kodrader
  • Variabler som lagras i minnet
  • Enhets- och mappplatser
  • Programinstallationsplatser
  • Inställningar för värdkonfiguration
  • Annan intern programinformation

Genom att fånga alla fel i ett program och tillhandahålla allmänna felmeddelanden, samt aktivera anpassade fel i IIS, kan du förhindra avslöjande av information. SQL Server databas- och .NET-undantagshantering, bland andra felhanteringsarkitekturer, är särskilt utförliga och mycket användbara för en skadlig användare som profilerar ditt program. Visa inte innehållet i en klass som härleds från .NET-undantagsklassen direkt och se till att du har rätt undantagshantering så att ett oväntat undantag inte oavsiktligt genereras direkt till användaren.

  • Ange allmänna felmeddelanden direkt till användaren som abstraherar bort specifik information som finns direkt i undantaget/felmeddelandet
  • Visa inte innehållet i en .NET-undantagsklass direkt för användaren
  • Generera traps för alla felmeddelanden och informera användaren om detta via ett allmänt felmeddelande som skickas till programklienten
  • Exponera inte innehållet i klassen Exception direkt för användaren, särskilt returvärdet från .ToString(), eller värdena för egenskaperna Message eller StackTrace. Logga den här informationen på ett säkert sätt och visa ett mer harmlöst meddelande för användaren

Implementera standardsidan för felhantering

Rubrik Information
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmänna
Attribut Ej tillämpligt
Referenser Redigera dialogrutan för inställningar av ASP.NET-felsidor
Steg

När ett ASP.NET program misslyckas och orsakar ett internt HTTP/1.x 500-serverfel, eller om en funktionskonfiguration (till exempel filtrering av begäranden) förhindrar att en sida visas, genereras ett felmeddelande. Administratörer kan välja om programmet ska visa ett eget meddelande för klienten, ett detaljerat felmeddelande till klienten eller ett detaljerat felmeddelande till localhost. Taggen <customErrors> i web.config har tre lägen:

  • På: Anger att anpassade fel är aktiverade. Om inget defaultRedirect-attribut har angetts visas ett allmänt fel för användarna. De anpassade felen visas för fjärrklienter och den lokala värden
  • Av: Anger att anpassade fel är inaktiverade. De detaljerade ASP.NET felen visas för fjärrklienter och den lokala värden
  • RemoteOnly: Anger att anpassade fel endast visas för fjärrklienter och att ASP.NET fel visas för den lokala värden. Detta är standardvärdet

web.config Öppna filen för programmet/webbplatsen och kontrollera att taggen har antingen <customErrors mode="RemoteOnly" /> eller <customErrors mode="On" /> har definierats.

Ange Distributionsmetod till Retail i IIS

Rubrik Information
Komponent Webbprogram
SDL-fas Distribution
Tillämpliga tekniker Allmänna
Attribut Ej tillämpligt
Referenser distributionselement (ASP.NET inställningsschema)
Steg

Växeln <deployment retail> är avsedd att användas av IIS-produktionsservrar. Den här växeln används för att hjälpa program att köras med bästa möjliga prestanda och minsta möjliga läckage av säkerhetsinformation genom att inaktivera programmets möjlighet att generera spårningsutdata på en sida, inaktivera möjligheten att visa detaljerade felmeddelanden för slutanvändare och inaktivera felsökningsväxeln.

Ofta aktiveras växlar och alternativ som är utvecklarfokuserade, till exempel spårning av misslyckade förfrågningar och felsökning, under aktiv utveckling. Vi rekommenderar att distributionsmetoden på alla produktionsservrar anges till fullversion. öppna filen machine.config och se till att <deployment retail="true" /> förblir inställd på sant.

Undantag bör misslyckas på ett säkert sätt

Rubrik Information
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmänna
Attribut Ej tillämpligt
Referenser Fel på ett säkert sätt
Steg Programmet bör misslyckas på ett säkert sätt. Alla metoder som returnerar ett booleskt värde, baserat på vilket visst beslut fattas, bör ha undantagsblocket noggrant skapat. Det finns många logiska fel på grund av vilka säkerhetsproblem som kryper in, när undantagsblocket skrivs vårdslöst.

Exempel

        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;
            }
        }

Metoden ovan returnerar alltid True om något undantag inträffar. Om slutanvändaren tillhandahåller en felaktigt formaterad URL, som webbläsaren respekterar, men Uri() konstruktorn inte gör det, utlöser detta ett undantag och offret förs till den giltiga men felaktiga URL:en.