Udostępnij za pośrednictwem

Ramka zabezpieczeń: Zarządzanie wyjątkami | Środki zaradcze

Produkt/usługa Artykuł
WCF
Internetowy interfejs API
Aplikacja internetowa

WCF — nie dołączaj węzła serviceDebug w pliku konfiguracji

Tytuł Szczegóły
Składnik WCF
Faza SDL Build
Zastosowalne technologie Ogólne, NET Framework 3
atrybutów N/A
Dokumentacja MSDN, Fortify Kingdom
Kroki usługi Windows Communication Framework (WCF) można skonfigurować w celu uwidocznienia informacji debugowania. Informacje debugowania nie powinny być używane w środowiskach produkcyjnych. Tag <serviceDebug> określa, czy funkcja informacji debugowania jest włączona dla usługi WCF. Jeśli atrybut includeExceptionDetailInFaults ma wartość true, informacje o wyjątku z aplikacji zostaną zwrócone klientom. Osoby atakujące mogą wykorzystać dodatkowe informacje uzyskane z danych wyjściowych debugowania w celu zainstalowania ataków ukierunkowanych na platformę, bazę danych lub inne zasoby używane przez aplikację.

Przykład

Następujący plik konfiguracji zawiera <serviceDebug> tag:

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

Wyłącz informacje debugowania w usłudze. Można to zrobić, usuwając <serviceDebug> tag z pliku konfiguracji aplikacji.

WCF — nie dołączaj węzła serviceMetadata do pliku konfiguracji

Tytuł Szczegóły
Składnik WCF
Faza SDL Build
Zastosowalne technologie Generyczny
atrybutów Ogólne, NET Framework 3
Dokumentacja MSDN, Fortify Kingdom
Kroki Publiczne ujawnianie informacji o usłudze może zapewnić osobom atakującym cenny wgląd w sposób, w jaki mogą wykorzystać tę usługę. Tag <serviceMetadata> włącza funkcję publikowania metadanych. Metadane usługi mogą zawierać poufne informacje, które nie powinny być publicznie dostępne. Co najmniej zezwalaj zaufanym użytkownikom na dostęp do metadanych i upewnij się, że niepotrzebne informacje nie są uwidocznione. Jeszcze lepiej, całkowicie wyłącz możliwość publikowania metadanych. Bezpieczna konfiguracja programu WCF nie będzie zawierać tagu <serviceMetadata> .

Upewnij się, że w ASP.NET Web API jest wykonywana właściwa obsługa wyjątków

Tytuł Szczegóły
Składnik Internetowy interfejs API
Faza SDL Build
Zastosowalne technologie MVC 5, MVC 6
atrybutów N/A
Dokumentacja Obsługa wyjątków w ASP.NET Web API, walidacja modelu w ASP.NET Web API
Kroki Domyślnie większość nieuchwyconych wyjątków w ASP.NET Web API jest tłumaczona na odpowiedź HTTP z kodem stanu 500, Internal Server Error

Przykład

Aby kontrolować kod stanu zwrócony przez interfejs API, można użyć HttpResponseException, jak pokazano poniżej:

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

Przykład

Aby uzyskać dalszą kontrolę nad odpowiedzią wyjątku, można użyć klasy, HttpResponseMessage jak pokazano poniżej:

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

Aby przechwycić nieobsługiwane wyjątki, które nie są typu HttpResponseException, można użyć filtrów wyjątków. Filtry wyjątków implementują System.Web.Http.Filters.IExceptionFilter interfejs. Najprostszym sposobem na napisanie filtru wyjątku jest wyprowadzenie z System.Web.Http.Filters.ExceptionFilterAttribute klasy i zastąpienie metody OnException.

Przykład

Oto filtr, który konwertuje NotImplementedException wyjątki na kod 501, Not Implementedstanu 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);
            }
        }
    }
}

Istnieje kilka sposobów rejestrowania filtru wyjątków webowego interfejsu API:

  • Sortowane według akcji
  • Przez kontroler
  • Globalnie

Przykład

Aby zastosować filtr do określonej akcji, dodaj filtr jako atrybut do akcji:

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

Przykład

Aby zastosować filtr do wszystkich akcji w obiekcie controller, dodaj filtr jako atrybut do controller klasy:

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

Przykład

Aby zastosować filtr globalnie do wszystkich kontrolerów interfejsu Web API, dodaj instancję filtru do kolekcji GlobalConfiguration.Configuration.Filters. Filtry wyjątków w tej kolekcji mają zastosowanie do dowolnej akcji kontrolera internetowego interfejsu API.

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

Przykład

W przypadku walidacji modelu można przekazać stan modelu do metody CreateErrorResponse, jak pokazano poniżej:

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

Zapoznaj się z linkami w sekcji dokumentacji, aby uzyskać dodatkowe informacje na temat wyjątkowej obsługi i weryfikacji modelu w ASP.NET Web API

Nie ujawniaj szczegółów zabezpieczeń w komunikatach o błędach

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Build
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja N/A
Kroki

Ogólne komunikaty o błędach są udostępniane bezpośrednio użytkownikowi bez uwzględniania poufnych danych aplikacji. Przykłady poufnych danych to:

  • Nazwy serwerów
  • Łańcuchy połączenia
  • Nazwy użytkowników
  • Passwords
  • Procedury SQL
  • Szczegóły dynamicznych błędów SQL
  • Ślad stosu i wiersze kodu
  • Zmienne przechowywane w pamięci
  • Lokalizacje dysków i folderów
  • Punkty instalacji aplikacji
  • Ustawienia konfiguracji hosta
  • Inne szczegóły aplikacji wewnętrznej

Przechwytywanie wszystkich błędów w aplikacji i wyświetlanie ogólnych komunikatów o błędach, a także włączanie błędów niestandardowych w IIS pomoże zapobiec ujawnieniu informacji. SQL Server jako baza danych oraz obsługa wyjątków .NET, jak i inne architektury obsługi błędów, są szczególnie szczegółowe i bardzo przydatne dla złośliwego użytkownika, który profiluje aplikację. Nie wyświetlaj bezpośrednio zawartości klasy pochodzącej z klasy .NET Exception i upewnij się, że masz odpowiednią obsługę wyjątków, aby nieoczekiwany wyjątek nie był przypadkowo zgłaszany bezpośrednio użytkownikowi.

  • Podaj ogólne komunikaty o błędach bezpośrednio użytkownikowi, które pomijają szczegółowe informacje zawarte bezpośrednio w komunikacie o wyjątku/błędzie.
  • Nie wyświetlaj zawartości klasy wyjątku .NET bezpośrednio do użytkownika
  • Przechwyć wszystkie komunikaty o błędach i, jeśli to właściwe, poinformuj użytkownika za pomocą standardowego komunikatu o błędzie wysłanego do klienta aplikacji.
  • Nie ujawniaj zawartości klasy Exception bezpośrednio użytkownikowi, zwłaszcza zwracanej wartości z .ToString(), lub wartości właściwości Message lub StackTrace. Bezpiecznie rejestruj te informacje i wyświetlaj użytkownikowi bardziej nieszkodliwy komunikat

Implementowanie domyślnej strony obsługi błędów

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Build
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja Edytuj ustawienia okna dialogowego stron błędów ASP.NET
Kroki

W przypadku, gdy aplikacja ASP.NET kończy się niepowodzeniem i wywołuje błąd HTTP/1.x 500 Wewnętrzny błąd serwera, lub gdy konfiguracja funkcji (na przykład filtrowanie żądań) uniemożliwia wyświetlenie strony, zostanie wygenerowany komunikat o błędzie. Administratorzy mogą wybrać, czy aplikacja powinna wyświetlać przyjazny komunikat dla klienta, szczegółowy komunikat o błędzie do klienta, czy szczegółowy komunikat o błędzie tylko do hosta lokalnego. Tag <customErrors> w web.config ma trzy tryby:

  • Na: Określa, że wyświetlanie błędów niestandardowych jest włączone. Jeśli nie określono atrybutu defaultRedirect, użytkownicy zobaczą błąd ogólny. Błędy niestandardowe są wyświetlane klientom zdalnym i hostowi lokalnemu
  • Wyłączone: Określa, że błędy niestandardowe są wyłączone. Szczegółowe błędy ASP.NET są wyświetlane klientom zdalnym i hostowi lokalnemu
  • RemoteOnly: Określa, że błędy niestandardowe są wyświetlane tylko klientom zdalnym, a błędy ASP.NET są wyświetlane na hoście lokalnym. Jest to wartość domyślna

Otwórz plik web.config dla aplikacji/witryny i upewnij się, że tag ma zdefiniowany <customErrors mode="RemoteOnly" /> lub <customErrors mode="On" />.

Ustaw metodę wdrażania na Retail w usługach IIS

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Wdrożenie
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja element deployment (schemat ustawień ASP.NET)
Kroki

Przełącznik <deployment retail> jest przeznaczony do użytku przez serwery IIS w środowisku produkcyjnym. Ten przełącznik ułatwia uruchamianie aplikacji z najlepszą możliwą wydajnością i najmniej możliwymi wyciekami informacji o bezpieczeństwie przez wyłączenie możliwości generowania danych śledzenia na stronie, wyłączanie możliwości wyświetlania szczegółowych komunikatów o błędach dla użytkowników końcowych oraz wyłączanie przełącznika debugowania.

Często przełączniki i ustawienia skoncentrowane na deweloperach, takie jak śledzenie nieudanych żądań i debugowanie, są włączane podczas aktywnego rozwoju. Zaleca się, aby metoda wdrażania na dowolnym serwerze produkcyjnym była ustawiona na sprzedaż detaliczną. otwórz plik machine.config i upewnij się, że <deployment retail="true" /> pozostaje ustawiona wartość true.

Wyjątki powinny bezpiecznie zakończyć się niepowodzeniem

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Build
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja Bezpieczne niepowodzenie
Kroki Aplikacja powinna bezpiecznie zakończyć się niepowodzeniem. Każda metoda zwracająca wartość logiczną, na podstawie której podjęto pewną decyzję, powinna mieć starannie utworzony blok wyjątków. Gdy blok wyjątków jest pisany nieostrożnie, pojawia się wiele błędów logicznych, które mogą prowadzić do problemów z zabezpieczeniami.

Przykład

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

Powyższa metoda zawsze zwróci wartość True, jeśli wystąpi jakiś wyjątek. Jeśli użytkownik końcowy poda źle sformułowany adres URL, który przeglądarka akceptuje, ale Uri() konstruktor nie, zostanie zgłoszony wyjątek, a ofiara zostanie przeniesiona do prawidłowego, lecz źle sformułowanego adresu URL.

  • Last updated on