Biztonsági keret: Kivételkezelés | Enyhítése

Termék/szolgáltatás Cikk
WCF
Webes API
Webalkalmazás

WCF – A serviceDebug csomópont nem szerepel a konfigurációs fájlban

Cím Részletek
Komponens WCF
SDL-fázis Épít
Alkalmazható technológiák Általános, NET-keretrendszer 3
Attribútumok N/A
Hivatkozások MSDN, Fortify Kingdom
Lépések Windows Kommunikációs keretrendszer (WCF) szolgáltatásai konfigurálhatók a hibakeresési információk felfedésére. A hibakeresési adatok éles környezetben nem használhatók. A <serviceDebug> címke meghatározza, hogy a hibakeresési információs funkció engedélyezve van-e egy WCF-szolgáltatáshoz. Ha az includeExceptionDetailInFaults attribútum értéke igaz, az alkalmazás kivételadatai vissza lesznek adva az ügyfeleknek. A támadók a kimenet hibakereséséből származó további információk felhasználásával csatlakoztathatják az alkalmazás által használt keretrendszerre, adatbázisra vagy egyéb erőforrásokra irányuló támadásokat.

Example

A következő konfigurációs fájl tartalmazza a címkét <serviceDebug> :

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

Tiltsa le a hibakeresési információkat a szolgáltatásban. Ezt úgy teheti meg, hogy eltávolítja a <serviceDebug> címkét az alkalmazás konfigurációs fájljából.

WCF – A serviceMetadata csomópont nem szerepel a konfigurációs fájlban

Cím Részletek
Komponens WCF
SDL-fázis Épít
Alkalmazható technológiák Általános
Attribútumok Általános, NET-keretrendszer 3
Hivatkozások MSDN, Fortify Kingdom
Lépések A szolgáltatásokkal kapcsolatos információk nyilvános felfedése értékes betekintést nyújthat a támadók számára a szolgáltatás kihasználásának módjába. A <serviceMetadata> címke lehetővé teszi a metaadatok közzétételét. A szolgáltatás metaadatai olyan bizalmas információkat tartalmazhatnak, amelyeket nem szabad nyilvánosan elérni. Legalább csak a megbízható felhasználók férhetnek hozzá a metaadatokhoz, és győződjön meg arról, hogy a szükségtelen információk nem kerülnek nyilvánosságra. Még jobb, ha teljesen letiltja a metaadatok közzétételének képességét. A biztonságos WCF-konfiguráció nem tartalmazza a címkét <serviceMetadata> .

Győződjön meg arról, hogy a megfelelő kivételkezelés elvégezve legyen az ASP.NET Web API-ban.

Cím Részletek
Komponens Webes API
SDL-fázis Épít
Alkalmazható technológiák MVC 5, MVC 6
Attribútumok N/A
Hivatkozások Kivétel kezelése ASP.NET Web API, Modell-ellenőrzés a ASP.NET Web API
Lépések Alapértelmezés szerint az ASP.NET Web API legtöbb kezeletlen kivétele HTTP-válaszra van lefordítva, amely státuszkódot tartalmaz 500, Internal Server Error.

Example

Az API HttpResponseException által visszaadott állapotkód szabályozásához az alábbiak szerint használható:

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

Example

A kivételválasz további szabályozásához az osztály az HttpResponseMessage alábbi módon használható:

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

Az olyan nem kezelt kivételek elfogásához, amelyek nem HttpResponseException típusúak, kivételszűrők használhatók. A kivételszűrők implementálják az interfészt System.Web.Http.Filters.IExceptionFilter . A kivételszűrők írásának legegyszerűbb módja, ha az System.Web.Http.Filters.ExceptionFilterAttribute osztályból származtatja, és felülbírálja az OnException metódust.

Example

Íme egy szűrő, amely a kivételeket NotImplementedException HTTP-állapotkóddá 501, Not Implementedalakítja:

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

A webes API-kivételszűrők regisztrálásának több módja is van:

  • Művelet szerint
  • Vezérlő szerint
  • Globálisan

Example

Ha a szűrőt egy adott műveletre szeretné alkalmazni, adja hozzá a szűrőt attribútumként a művelethez:

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

Example

Ha a szűrőt az összes műveletre egy controller kívánja alkalmazni, adja hozzá a szűrőt attribútumként az controller osztályhoz.

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

Example

Ha globálisan szeretné alkalmazni a szűrőt az összes webes API-vezérlőre, adja hozzá a szűrő egy példányát a GlobalConfiguration.Configuration.Filters gyűjteményhez. A gyűjtemény kivételszűrői minden webes API-vezérlőműveletre érvényesek.

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

Example

A modellérvényesítéshez a modell állapota átadható a CreateErrorResponse metódusnak az alábbiak szerint:

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

A ASP.NET Web API kivételes kezelésével és modellérvényesítésével kapcsolatos további részletekért tekintse meg a hivatkozások szakaszban található hivatkozásokat.

Ne tegye közzé a biztonsági részleteket a hibaüzenetekben

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Épít
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások N/A
Lépések

Az általános hibaüzenetek közvetlenül a felhasználóhoz kerülnek bizalmas alkalmazásadatok hozzáadása nélkül. A bizalmas adatok például a következők:

  • Kiszolgálónevek
  • Kapcsolati karakterláncok
  • Felhasználónevek
  • Passwords
  • SQL-eljárások
  • A dinamikus SQL-hibák részletei
  • Verem nyomkövetés és kódsorok
  • A memóriában tárolt változók
  • Meghajtó- és mappahelyek
  • Alkalmazástelepítési pontok
  • Szerver konfigurációs beállításai
  • Egyéb belső alkalmazásadatok

Az alkalmazáson belüli összes hiba csapdába ejtése és általános hibaüzenetek megjelenítése, valamint az egyéni hibák engedélyezése az IIS-ben segít elkerülni az információszivárgást. SQL Server adatbázis és .NET kivételkezelés– többek között a hibakezelési architektúrák – különösen részletesek és rendkívül hasznosak az alkalmazást profilozó rosszindulatú felhasználók számára. Ne jelenítse meg közvetlenül a .NET Exception osztály leszármaztatott osztályainak tartalmát, és győződjön meg róla, hogy a megfelelő kivételkezelést alkalmazza, hogy véletlenül se forduljon elő, hogy egy váratlan kivétel közvetlenül a felhasználóhoz jusson.

  • Adjon meg általános hibaüzeneteket közvetlenül annak a felhasználónak, aki a kivételben/hibaüzenetben közvetlenül talált konkrét részleteket kivonatol
  • Ne jelenjen meg közvetlenül a felhasználónak .NET kivételosztály tartalma
  • Az összes hibaüzenet elfogása, és ha szükséges, értesítse a felhasználót az alkalmazás kliensnek küldött általános hibaüzenettel.
  • Ne tegye közvetlenül a felhasználó számára elérhetővé a Kivétel osztály tartalmát, különösen az Üzenet vagy a StackTrace tulajdonságok visszatérési értékét .ToString(). Biztonságosan naplózza ezeket az információkat, és jelenítsen meg egy ártalmatlanabb üzenetet a felhasználónak

Alapértelmezett hibakezelő oldal implementálása

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Épít
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások A ASP.NET hibalapok beállításainak párbeszédpanel szerkesztése
Lépések

Ha egy ASP.NET-alkalmazás meghiúsul, és HTTP/1.x 500 belső kiszolgálóhibát okoz, vagy egy funkciókonfiguráció (például a kérésszűrés) megakadályozza a lapok megjelenítését, hibaüzenet jelenik meg. A rendszergazdák eldönthetik, hogy az alkalmazásnak rövid üzenetet kell-e megjelenítenie az ügyfélnek, részletes hibaüzenetet kell-e adni az ügyfélnek, vagy csak a localhostnak kell részletes hibaüzenetet megjelenítenie. A <customErrors> web.config címkéjének három módja van:

  • Bekapcsolva: Megadja, hogy az egyéni hibák engedélyezve vannak. Ha nincs megadva defaultRedirect attribútum, a felhasználók általános hibát tapasztalnak. Az egyéni hibák megjelennek a távoli ügyfeleknek és a helyi gépen.
  • Ki: Megadja, hogy az egyéni hibák le vannak tiltva. A részletes ASP.NET hibák megjelennek a távoli ügyfelek és a helyi gazdagép számára
  • RemoteOnly: Meghatározza, hogy a testreszabott hibák csak a távoli ügyfelek számára jelenjenek meg, míg az ASP.NET hibák a helyi gazdagépen legyenek láthatóak. Ez az alapértelmezett érték

Nyissa meg az web.config alkalmazás/hely fájljának megnyitását, és győződjön meg arról, hogy a címke rendelkezik <customErrors mode="RemoteOnly" /> vagy <customErrors mode="On" /> definiálva van.

Állítsa az üzembehelyezési módszert kiskereskedelemre az IIS-ben.

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Üzembe helyezés
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások deployment elem (ASP.NET Beállításséma)
Lépések

A <deployment retail> kapcsoló termelési IIS-kiszolgálók általi használatra szánt. Ez a kapcsoló segít az alkalmazásoknak a lehető legjobb teljesítménnyel és a lehető legkevesebb biztonsági információszivárgással futni azáltal, hogy letiltja az alkalmazás nyomkövetési kimenetének létrehozását egy lapon, letiltja a részletes hibaüzenetek végfelhasználóknak való megjelenítését, és letiltja a hibakeresési kapcsolót.

Az aktív fejlesztés során gyakran engedélyezve vannak a fejlesztőközpontú kapcsolók és beállítások, például a sikertelen kérelmek nyomon követése és hibakeresése. Javasoljuk, hogy a telepítési módot bármely éles szerveren kereskedelmi verzióra állítsa. nyissa meg a machine.config fájlt, és győződjön meg arról, hogy az <deployment retail="true" /> igaz értékre van állítva.

A kivételeknek biztonságosan sikertelennek kell lennie

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Épít
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások Sikertelenség biztonságosan
Lépések Az alkalmazásnak biztonságosan sikertelennek kell lennie. Minden olyan metódusnak, amely logikai értéket ad vissza, amely alapján bizonyos döntés születik, gondosan létre kell hoznia a kivételblokkot. Számos logikai hiba van, amelyek miatt biztonsági problémák csúsznak be, amikor a kivételblokkot gondtalanul írják.

Example

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

A fenti módszer mindig Igaz értéket ad vissza, ha valamilyen kivétel történik. Ha a végfelhasználó helytelen formátumú URL-címet ad meg, amelyet a böngésző tiszteletben tart, de a Uri() konstruktor nem, ez kivételt fog eredményezni, és az áldozatot a rendszer az érvényes, de helytelen formátumú URL-címre viszi.