Dela via

Säkerhetsram: Undantagshantering | Mitigations

Produkt/tjänst Artikel
WCF
Webb-API
Webbapplikation

WCF – Inkludera inte serviceDebug-noden i konfigurationsfilen

Titel Detaljer
Komponent WCF
SDL-fasen Skapa
Tillämpliga tekniker Generisk, NET Framework 3
Attribut N/A
Referenser MSDN, Fortify Kingdom
Instruktioner Windows Communication Framework-tjänster (WCF) 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 klienter. Angripare kan utnyttja den ytterligare information de får från felsökning av 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 du göra genom att ta bort taggen <serviceDebug> från programmets konfigurationsfil.

WCF – Inkludera inte serviceMetadata-noden i konfigurationsfilen

Titel Detaljer
Komponent WCF
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Generisk, NET Framework 3
Referenser MSDN, Fortify Kingdom
Instruktioner Att offentligt exponera information om en tjänst kan ge angripare värdefull insikt i hur de kan utnyttja tjänsten. Taggen <serviceMetadata> aktiverar funktionen för metadatapublicering. Tjänstmetadata kan innehålla känslig information som inte bör vara offentligt tillgänglig. Tillåt endast betrodda användare att komma åt metadata och se till att onödig information inte exponeras. Ännu bättre är att 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 Web API

Titel Detaljer
Komponent Webb-API
SDL-fasen Skapa
Tillämpliga tekniker MVC 5, MVC 6
Attribut N/A
Referenser Exception-hantering i ASP.NET Web API, Model-validering i ASP.NET Web API
Instruktioner Som standardinställning översätts de flesta ohanterade undantag i ASP.NET Web API till ett HTTP-svar med statuskod 500, Internal Server Error

Exempel

För att styra den statuskod som returneras av API:et HttpResponseException, kan du använda det som visas 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 över 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 undantagsfilter för webb-API:

  • Efter åtgärd
  • Efter styrenhet
  • Globalt

Exempel

Om du vill tillämpa filtret på en specifik åtgärd lägger du till filtret som ett attribut i å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 åtgärder för webb-API-kontrollanter.

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

Exempel

För modellverifiering 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...
}

Mer information om exceptionell hantering och modellvalidering finns i länkarna i referensavsnittet i ASP.NET Web API

Exponera inte säkerhetsinformation i felmeddelanden

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut N/A
Referenser N/A
Instruktioner

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
  • Passwords
  • SQL-procedurer
  • Information om dynamiska SQL-fel
  • Stackspårning och kodrader
  • Variabler som lagras i minnet
  • Lagringsenhets- och mappplatser
  • Programinstallationsplatser
  • Inställningar för värdkonfiguration
  • Övriga interna applikationsdetaljer

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 att information avslöjas. 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 direkt från klassen .NET Exception 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
  • Fånga upp alla felmeddelanden och vid behov informera användaren via ett generiskt felmeddelande som skickas till applikationsklienten.
  • Exponera inte innehållet i undantagsklassen direkt för användaren, särskilt returvärdet från .ToString()eller värdena för egenskaperna Meddelande 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 sidan För standardfelhantering

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut N/A
Referenser Redigera ASP.NET felsidors inställningar dialogruta
Instruktioner

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 vänligt meddelande till 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 ser användarna ett allmänt fel. De anpassade felen visas för fjärrklienterna och för den lokala värddatorn
  • Av: Anger att anpassade fel är inaktiverade. De detaljerade ASP.NET-felen visas för fjärrklienterna och för den lokala värddatorn.
  • RemoteOnly: Anger att anpassade fel endast visas för fjärrklienter och att ASP.NET-fel visas för den lokala värden. Det här är standardvärdet

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

Ange distributionsmetod till Retail i IIS

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Distribution
Tillämpliga tekniker Allmän
Attribut N/A
Referenser deployment-element (schema för ASP.NET inställningar)
Instruktioner

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.

Under aktiv utveckling aktiveras ofta växlar och alternativ som är utvecklarfokuserade, såsom spårning av misslyckade begäranden och felsökning. Vi rekommenderar att distributionsmetoden på alla produktionsservrar anges till retail. öppna filen machine.config och se till att <deployment retail="true" /> förblir inställd på true.

Undantag bör hanteras säkert

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut N/A
Referenser Misslyckas säkert
Instruktioner Applikationen ska misslyckas på ett säkert sätt. Alla metoder som returnerar ett booleskt värde, baserat på vilket vissa beslut fattas, bör ha undantagsblocket noggrant skapat. Det finns många logiska fel som beror på vilka säkerhetsproblem som kryper in när undantagsblocket skrivs slarvigt.

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 utformad URL, som webbläsaren respekterar, men Uri() konstruktorn inte gör det, utlöser detta ett undantag och offret kommer att tas till den giltiga men felaktiga URL:en.

  • Last updated on