Ramka zabezpieczeń: zarządzanie wyjątkami | Czynniki
| 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:
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.
|
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
|
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 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 |
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.