Udostępnij za pośrednictwem

Ramka zabezpieczeń: zarządzanie wyjątkami | Czynniki

  • Artykuł
Produkt/usługa Artykuł
WCF
Interfejs API sieci Web
Aplikacja internetowa

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

Tytuł Szczegóły
Składnik WCF
Faza SDL Kompilacja
Odpowiednie technologie Ogólne, NET Framework 3
Atrybuty Nie dotyczy
Odwołania MSDN, Fortify Kingdom
Kroki Usługi Windows Communication Framework (WCF) można skonfigurować w celu uwidocznienia informacji o debugowaniu. 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 do klientów. Osoby atakujące mogą wykorzystać dodatkowe informacje uzyskane z debugowania danych wyjściowych 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 o debugowaniu 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 Kompilacja
Odpowiednie technologie Ogólny
Atrybuty Ogólne, NET Framework 3
Odwołania MSDN, Fortify Kingdom
Kroki Publiczne ujawnienie informacji o usłudze może zapewnić osobom atakującym cenny wgląd w sposób, w jaki mogą wykorzystać 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ą ujawniane. Jeszcze lepiej, całkowicie wyłącz możliwość publikowania metadanych. Bezpieczna konfiguracja WCF nie będzie zawierać tagu <serviceMetadata> .

Upewnij się, że prawidłowa obsługa wyjątków jest wykonywana w interfejsie API sieci Web ASP.NET

Tytuł Szczegóły
Składnik Interfejs API sieci Web
Faza SDL Kompilacja
Odpowiednie technologie MVC 5, MVC 6
Atrybuty Nie dotyczy
Odwołania Obsługa wyjątków w internetowym interfejsie API ASP.NET, walidacja modelu w internetowym interfejsie API ASP.NET
Kroki Domyślnie większość nieprzechwyconych wyjątków w internetowym interfejsie API ASP.NET jest tłumaczona na odpowiedź HTTP z kodem stanu 500, Internal Server Error

Przykład

Aby kontrolować kod stanu zwrócony przez interfejs API, HttpResponseException można go użyć, 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ą na wyjątek, 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 internetowego interfejsu API:

  • Według akcji
  • Według kontrolera
  • 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 internetowego interfejsu API, dodaj wystąpienie 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 szczegóły dotyczące wyjątkowej obsługi i weryfikacji modelu w ASP.NET internetowym interfejsie API

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

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Kompilacja
Odpowiednie technologie Ogólny
Atrybuty Nie dotyczy
Odwołania Nie dotyczy
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
  • Parametry połączeń
  • Nazwy użytkownika
  • Hasła
  • 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

Uwięzienie wszystkich błędów w aplikacji i dostarczanie ogólnych komunikatów o błędach, a także włączenie błędów niestandardowych w usługach IIS pomoże zapobiec ujawnieniu informacji. SQL Server bazy danych i obsługi wyjątków platformy .NET, między innymi architektury obsługi błędów, są szczególnie pełne i bardzo przydatne dla złośliwego użytkownika profilowania aplikacji. Nie wyświetlaj bezpośrednio zawartości klasy pochodzącej z klasy wyjątków platformy .NET i upewnij się, że masz odpowiednią obsługę wyjątków, aby nieoczekiwany wyjątek nie został przypadkowo zgłoszony bezpośrednio do użytkownika.

  • Udostępnij ogólne komunikaty o błędach bezpośrednio użytkownikowi, które wyodrębnią określone szczegóły znajdujące się bezpośrednio w komunikacie o wyjątku/błędzie
  • Nie wyświetlaj zawartości klasy wyjątków platformy .NET bezpośrednio do użytkownika
  • Pułapka wszystkich komunikatów o błędach i, jeśli jest to odpowiednie, poinformuj użytkownika za pośrednictwem ogólnego komunikatu o błędzie wysłanego do klienta aplikacji
  • Nie udostępniaj zawartości klasy Exception bezpośrednio użytkownikowi, zwłaszcza wartości zwracanej z .ToString()klasy , ani 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 Kompilacja
Odpowiednie technologie Ogólny
Atrybuty Nie dotyczy
Odwołania Okno dialogowe Edytowanie ustawień stron błędów ASP.NET
Kroki

Jeśli aplikacja ASP.NET ulegnie awarii i spowoduje wyświetlenie strony HTTP/1.x 500 Wewnętrzny błąd serwera lub 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 dla klienta, czy szczegółowy komunikat o błędzie tylko do hosta lokalnego. Tag <customErrors> w web.config ma trzy tryby:

  • Na: Określa, że błędy niestandardowe są 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 dla klientów zdalnych, a ASP.NET błędy są wyświetlane na hoście lokalnym. Jest to wartość domyślna

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

Ustaw metodę wdrożenia na wartość Retail w usługach IIS

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Wdrożenie
Odpowiednie technologie Ogólny
Atrybuty Nie dotyczy
Odwołania deployment, element (schemat ustawień ASP.NET)
Kroki

Przełącznik <deployment retail> jest przeznaczony do użytku przez produkcyjne serwery USŁUG IIS. Ten przełącznik służy do ułatwiania uruchamiania aplikacji z najlepszą możliwą wydajnością i najmniej możliwymi wyciekami informacji zabezpieczających, wyłączając możliwość generowania danych wyjściowych śledzenia na stronie, wyłączając możliwość wyświetlania szczegółowych komunikatów o błędach dla użytkowników końcowych i wyłączania przełącznika debugowania.

Często przełączniki i opcje skoncentrowane na deweloperach, takie jak śledzenie żądań niepomyślnych i debugowanie, są włączane podczas aktywnego programowania. 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 Kompilacja
Odpowiednie technologie Ogólny
Atrybuty Nie dotyczy
Odwołania 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. Istnieje wiele błędów logicznych, z powodu których problemy z zabezpieczeniami wkradają się, gdy blok wyjątków jest zapisywany nieostrojnie.

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, to przeglądarka szanuje, ale Uri() konstruktor nie, zgłosi wyjątek, a ofiara zostanie przeniesiona do prawidłowego, ale źle sformułowanego adresu URL.